Re: epoll exposure

[Tobias Nygren <tnn%NetBSD.org@localhost>]

On Sat, 12 Aug 2023 19:21:06 -0400
Christos Zoulas <christos%zoulas.com@localhost> wrote:

> I really want to understand what's going on here (why do we think that
> our epoll implementation is broken in a way that will affect applications).

jperkin@ might be able to explain what the issues with Illumos are,
but I guess the problems are of different nature than the NetBSD case.

The use case that concerns me as far as NetBSD goes is networking
daemons. Daemons that use worker process pools may pass an epoll
descriptor rather than the listening fd to workers via a fork(2). I
expect this to be an at least somewhat idiomatic pattern as it is
suggested to do it this way in the Linux epoll(7) man page[1].

A similar situation arises with daemons that reload their configuration
via the classic SIGHUP + fork(2) mechanism. If that is done from within
the event loop I guess we lose?

I would prefer the above scenarios are tested and known to work before
we advertise the functionality by default. But it doesn't sound from
the discussion that fixing descriptor inheritance is trivial.

Kind regards,
-Tobias

[1] Last paragraph of the "Level-triggered and edge-triggered" section.