On Sat, 12 Aug 2023 19:21:06 -0400 Christos Zoulas <chris...@zoulas.com> 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.
