Re: Remove latch.c workaround for Linux < 2.6.27

On Sat, Feb 27, 2021 at 9:01 PM Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
> On 27 February 2021 01:10:23 EET, Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> >Commit 82ebbeb0 added a workaround for (already in 2017) ancient Linux
> >kernels with no EPOLL_CLOEXEC. I don't see any such systems in the
> >build farm today (and if there is one hiding in there somewhere, it's
> >well past time to upgrade). I'd like to rip that code out, because
> >I'm about to commit some new code that uses another 2.6.17+
> >XXX_CLOEXEC flag, and it'd be silly to have to write new workaround
> >code for that too, and a contradiction to have fallback code in one
> >place but not another. Any objections?
>
> What happens if you try to try to compile or run on such an ancient kernel? Does it fall back to something else? Can you still make it work with different configure options?
>
> I'm just curious, not objecting.

With this patch, I guess you'd have to define WAIT_USE_POLL. I
suppose we could fall back to that automatically if EPOLL_CLOEXEC
isn't defined, if anyone thinks that's worth bothering with.

Even though Linux < 2.6.17 is not relevant, one thing I have wondered
about is what other current OSes might have copied Linux's epoll API
and get me into trouble by being incomplete. So far I have found only
illumos, based on googling about OSes that are in our build farm (my
idea of what OSes we support in some sense), and BF animal damselfly's
configure output seems to confirm that it does have it. Googling
tells me that it does seem to have the full modern version of the API,
so fingers crossed (looks like it also has signalfd() too, which is
interesting for my latch optimisation patch which assumes that if you
have epoll you also have signalfd).