Tarantool development patches archive
 help / color / mirror / Atom feed
From: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>
To: Timur Safin <tsafin@tarantool.org>,
	Cyrill Gorcunov <gorcunov@tarantool.org>
Cc: tarantool-patches@dev.tarantool.org
Subject: Re: [Tarantool-patches] [PATCH v1.1] evio: workaround for wsl1 so_linger assertion
Date: Mon, 16 Mar 2020 23:35:46 +0100	[thread overview]
Message-ID: <8b260724-43f4-ea28-44f8-2ed423ea410e@tarantool.org> (raw)
In-Reply-To: <005501d5fbb3$7c2895d0$7479c170$@tarantool.org>

Hi! Thanks for the patch!

Please, keep branch link in each new email thread.

On 16/03/2020 17:53, 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.
> 
> Acked-by: Cyrill Gorcunov <gorcunov@gmail.com>
> ---
>  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..c6b19f379 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_WSL1_WORKAROUND_ENABLED=1")
> +    endif()

To be more consistent I would better call it TARGET_OS_WSL1.
Since we already have TARGET_OS_LINUX, TARGET_OS_FREEBSD,
TARGET_OS_DEBIAN_FREEBSD, TARGET_OS_NETBSD, TARGET_OS_DARWIN.

Besides, it would be consistent with other similar examples
such as fio_filename(), load_cfg(), make_pipe(), and so on. They
use TARGET_OS_* name.

> +
>  elseif (${CMAKE_SYSTEM_NAME} STREQUAL "kFreeBSD")
>      set(TARGET_OS_FREEBSD 1)
>      set(TARGET_OS_DEBIAN_FREEBSD 1)
> @@ -19,6 +28,7 @@ elseif (${CMAKE_SYSTEM_NAME} STREQUAL "kFreeBSD")
>      add_definitions("-D_FILE_OFFSET_BITS=64")
>      find_package_message(PLATFORM "Building for Debian/kFreeBSD"
>          "${CMAKE_SYSTEM_NAME}")
> +

Please, omit not necessary diff. This and other new empty lines
below.

>  elseif (${CMAKE_SYSTEM_NAME} STREQUAL "FreeBSD")
>      set(TARGET_OS_FREEBSD 1)
>      find_package_message(PLATFORM "Building for FreeBSD" "${CMAKE_SYSTEM_NAME}")
> @@ -57,9 +67,11 @@ elseif (${CMAKE_SYSTEM_NAME} STREQUAL "FreeBSD")
>                          "system libraries is not supported")
>      endif()
>      unset(REAL_OPENSSL_ROOT_DIR)
> +
>  elseif (${CMAKE_SYSTEM_NAME} STREQUAL "NetBSD")
>      set(TARGET_OS_NETBSD 1)
>      find_package_message(PLATFORM "Building for NetBSD" "${CMAKE_SYSTEM_NAME}")
> +
>  elseif (${CMAKE_SYSTEM_NAME} STREQUAL "Darwin")
>      set(TARGET_OS_DARWIN 1)
>  
> @@ -154,6 +166,7 @@ elseif (${CMAKE_SYSTEM_NAME} STREQUAL "Darwin")
>              endif()
>          endif()
>      endif()
> +
>  else()
>      message (FATAL_ERROR "Unsupported platform -- ${CMAKE_SYSTEM_NAME}")
>  endif()

  reply	other threads:[~2020-03-16 22:35 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <bb3eef527b48bdd3aacddc27e0597ceedcb84987.1584371177.git.tsafin@tarantool.org>
2020-03-16 16:53 ` Timur Safin
2020-03-16 22:35   ` Vladislav Shpilevoy [this message]
2020-03-17 14:40     ` Timur Safin
2020-03-17 21:27       ` Vladislav Shpilevoy
2020-03-18  7:12         ` Timur Safin
2020-03-19 10:27 ` [Tarantool-patches] [PATCH v1.2] " Timur Safin
2020-03-19 10:52   ` Cyrill Gorcunov
2020-03-19 11:07     ` Timur Safin
2020-03-22 19:21   ` Vladislav Shpilevoy
2020-03-23 23:12     ` Vladislav Shpilevoy

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=8b260724-43f4-ea28-44f8-2ed423ea410e@tarantool.org \
    --to=v.shpilevoy@tarantool.org \
    --cc=gorcunov@tarantool.org \
    --cc=tarantool-patches@dev.tarantool.org \
    --cc=tsafin@tarantool.org \
    --subject='Re: [Tarantool-patches] [PATCH v1.1] 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