Date: Thu, 30 Sep 2021 08:37:44 -0400
From: Christos Zoulas <chris...@zoulas.com>
Message-ID: <49c53880-d427-489d-92fa-881cd01b5...@zoulas.com>
| I have committed it to head, but I want to make sure that everything is
| ok and that people don't prefer to fix it via a fork hook,
There's nothing wrong with that as a fix for the DNS resolver issue, but
I suspect that the underlying issue isn't fixed this way - any process that
has a kqueue open (by some code in some library, so not known to the
application, as here) will face the same problem and so need a similar
solution.
I'd suggest that when a fork happens, rather than closing the kqueue fd
in the child, rather it be left open, but redirected to a nothing object
(one which simply returns errors on almost all operations but ones that
only affect the fd (eg: dup) and close().)
That would still need something like your fix if the kqueue is desired
to work (again) in the child, but would avoid issues like the one in
question where the fd is recorded somewhere, and used after that same
fd has been reassigned elsewhere.
Alternatively of course, simply make kqueue remain open across fork, it
already needs to be able to handle multiple fd's aimed at the same queue,
right? After all the fd can still be dup'd.
kre
