From: Cyrill Gorcunov <gorcunov@gmail.com>
To: Timur Safin <tsafin@tarantool.org>
Cc: Cyrill Gorcunov <gorcunov@tarantool.org>,
Vladislav Shpilevoy <v.shpilevoy@tarantool.org>,
tarantool-patches@dev.tarantool.org
Subject: Re: [Tarantool-patches] [PATCH] evio: workaround for wsl1 so_linger assertion
Date: Mon, 16 Mar 2020 18:32:02 +0300 [thread overview]
Message-ID: <20200316153202.GB27301@uranus> (raw)
In-Reply-To: <18ca01d5fba7$1c19a2d0$544ce870$@tarantool.org>
On Mon, Mar 16, 2020 at 06:25:22PM +0300, Timur Safin wrote:
> SO_LINGER makes no much sense for unix-sockets, and Microsoft WSL
> is returning EINVAL if setsockopts called for SO_LINGER over unix
> sockets:
>
> [004] 2020-03-11 18:42:29.592 [29182] main/102/app sio.c:169 !> SystemError setsockopt(SO_LINGER), called on fd 16, aka
> [004] 2020-03-11 18:42:29.592 [29182] main/102/app F> can't initialize storage: setsockopt(SO_LINGER), called on fd 16,
> [004] 2020-03-11 18:42:29.592 [29182] main/102/app F> can't initialize storage: setsockopt(SO_LINGER), called on fd 16,
>
> And it's sort of correct here, but the problem is Linux is simply
> silently ignoring it, which passes tests.
>
> After much debates we decided to work-around this case via CMAKE
> define.
>
> NB! In a future (April/May 2020), when WSL2 with full Linux kernel
> would be released we should disable this check.
> ---
>
> This patch replaces prior one tsafin/gh-4659-wsl-no-linger-assert because original
> approach considered unsafe, and we rather want to workaround it via CMake instead.
>
>
> Branch: https://github.com/tarantool/tarantool/tree/tsafin/wsl1-no-linger-assert
>
> cmake/os.cmake | 13 +++++++++++++
> src/lib/core/evio.c | 2 ++
> 2 files changed, 15 insertions(+)
>
> diff --git a/cmake/os.cmake b/cmake/os.cmake
> index 0ed554b9b..ee8870d21 100644
> --- a/cmake/os.cmake
> +++ b/cmake/os.cmake
> @@ -11,6 +11,15 @@ if (${CMAKE_SYSTEM_NAME} STREQUAL "Linux")
> # (see man page for feature_test_macros).
> add_definitions("-D_FILE_OFFSET_BITS=64")
> find_package_message(PLATFORM "Building for Linux" "${CMAKE_SYSTEM_NAME}")
> +
> + # There are some subtle differences in Linux kernel calls
> + # implementation under WSL1 (which should go away with WSL2 kernel)
> + # so for a moment we introduce a way to distinguish Linux and
> + # Microsoft/WSL1
> + if (${CMAKE_SYSTEM} MATCHES "Linux-.*-Microsoft")
> + add_definitions("-DTARANTOOL_WSL_WORKAROUND_ENABLED=1")
> + endif()
> +
Great! Thanks a huge, Timur! Since you mentioned WSL2 maybe we should
name it -DTARANTOOL_WSL_1 ? I don't insist though.
Acked-by: Cyrill Gorcunov <gorcunov@gmail.com>
next prev parent reply other threads:[~2020-03-16 15:32 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-16 15:25 Timur Safin
2020-03-16 15:32 ` Cyrill Gorcunov [this message]
2020-03-16 16:04 ` Timur Safin
2020-03-16 16:06 ` Cyrill Gorcunov
2020-03-16 15:31 [Tarantool-patches] Отзыв: " Тимур Сафин
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200316153202.GB27301@uranus \
--to=gorcunov@gmail.com \
--cc=gorcunov@tarantool.org \
--cc=tarantool-patches@dev.tarantool.org \
--cc=tsafin@tarantool.org \
--cc=v.shpilevoy@tarantool.org \
--subject='Re: [Tarantool-patches] [PATCH] evio: workaround for wsl1 so_linger assertion' \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox