From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp60.i.mail.ru (smtp60.i.mail.ru [217.69.128.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id 6D0554696C3 for ; Mon, 20 Apr 2020 09:31:01 +0300 (MSK) Date: Mon, 20 Apr 2020 09:30:50 +0300 From: Alexander Turenko Message-ID: <20200420063050.twyrcveukpfwt7cu@tkn_work_nb> References: <1581360313.873049294@f221.i.mail.ru> <20200215175046.GE19902@atlas> <20200215201903.z6b7v33mo5ea7k4c@tkn_work_nb> <20200217074052.GA15384@atlas> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20200217074052.GA15384@atlas> Subject: Re: [Tarantool-patches] [PATCH] libev: unlimited select flag did not work on mac List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Konstantin Osipov , Kirill Yukhin Cc: Vladislav Shpilevoy , tarantool-patches@dev.tarantool.org On Mon, Feb 17, 2020 at 10:40:52AM +0300, Konstantin Osipov wrote: > * Alexander Turenko [20/02/15 23:22]: > > > Is it fixed in the upstream? Why is noone complaining in the > > > upstream? Is there a bug in the upstream? > > > > Let me read changelog for you: > > Well, I guess the commit comment should say that this is only an > update from the upstream. > > Let me read third_party/README for you! > > How to update libev > =================== > > Remove Tarantool patches (see csv diff -U8). > cvs up > Add patches back. > > Did the patch follow the procedure? If it did, it should clearly > state that it updated libev, and to which version. This have sense. But I would include the backport of the fix in the upcoming release. Pushed to Totktonada/gh-3867-fix-select-on-mac-os-full-ci and shown below. CCed Kirill. commit aba11b2742393abc660726cefc0ca63f6920e700 Author: Alexander Turenko Date: Mon Apr 20 02:50:27 2020 +0300 libev: backport select()'s limit workaround As stated in the 'OS/X AND DARWIN BUGS' section of the libev documentation [1], kqueue() and poll() have known problems on Mac OS, so the library uses select() on Mac OS (it is the build time default). The library however uses the trick to overcome 1024 fds limit: libev sets the undocumented macro _DARWIN_UNLIMITED_SELECT, which enables linking against select() implementation without the limit. The magic macro stops working at some point around Mac OS 10.10 (see [2]), because it was defined after inclusion. For recent Mac OS versions the macro has effect only when it is defined before inclusion. The macro definition was [moved][3] in libev 4.25. Excerpt from the changelog [4]: | 4.25 Fri Dec 21 07:49:20 CET 2018 | <...> | - move the darwin select workaround higher in ev.c, as newer versions of | darwin managed to break their broken select even more. More proper fix would be updating of libev to a newer version, however I would postpone it until a moment when we'll have a time to properly test everything with a new version of the library. [1]: http://pod.tst.eu/http://cvs.schmorp.de/libev/ev.pod#OS_X_AND_DARWIN_BUGS [2]: http://lists.schmorp.de/pipermail/libev/2018q2/002788.html [3]: http://cvs.schmorp.de/libev/ev.c?r1=1.482&r2=1.483 [4]: http://cvs.schmorp.de/libev/Changes?view=markup Fixes #3867 Fixes #4673 Investigated-by: Maria Khaydich Co-authored-by: Maria Khaydich diff --git a/third_party/libev/ev.c b/third_party/libev/ev.c index 6a2648591..8f0045901 100644 --- a/third_party/libev/ev.c +++ b/third_party/libev/ev.c @@ -164,6 +164,16 @@ #endif +/* OS X, in its infinite idiocy, actually HARDCODES + * a limit of 1024 into their select. Where people have brains, + * OS X engineers apparently have a vacuum. Or maybe they were + * ordered to have a vacuum, or they do anything for money. + * This might help. Or not. + * Note that this must be defined early, as other include files + * will rely on this define as well. + */ +#define _DARWIN_UNLIMITED_SELECT 1 + #include #include #include @@ -211,14 +221,6 @@ # undef EV_AVOID_STDIO #endif -/* OS X, in its infinite idiocy, actually HARDCODES - * a limit of 1024 into their select. Where people have brains, - * OS X engineers apparently have a vacuum. Or maybe they were - * ordered to have a vacuum, or they do anything for money. - * This might help. Or not. - */ -#define _DARWIN_UNLIMITED_SELECT 1 - /* this block tries to deduce configuration from header-defined symbols and defaults */ /* try to deduce the maximum number of signals on this platform */