[Tarantool-patches] [PATCH] libev: unlimited select flag did not work on mac

[Alexander Turenko]

On Mon, Feb 17, 2020 at 10:40:52AM +0300, Konstantin Osipov wrote:
> * Alexander Turenko <alexander.turenko at tarantool.org> [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 <alexander.turenko at tarantool.org>
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 <sys/time.h> inclusion.  For recent
    Mac OS versions the macro has effect only when it is defined before
    <sys/time.h> 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 <maria.khaydich at tarantool.org>
    Co-authored-by: Maria Khaydich <maria.khaydich at tarantool.org>

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 <stdlib.h>
 #include <string.h>
 #include <fcntl.h>
@@ -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 */