> On Sep 30, 2021, at 3:08 PM, Robert Elz <kre%munnari.OZ.AU@localhost> wrote: > > Date: Thu, 30 Sep 2021 08:37:44 -0400 > From: Christos Zoulas <christos%zoulas.com@localhost> > Message-ID: <49C53880-D427-489D-92FA-881CD01B5FD9%zoulas.com@localhost> > > | 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. That is correct. > 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 definitely make debugging easier, since we are not going to be closing random fd's :-) but still the program will be broken. > 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. I totally agree with that, and I don't understand the reason it is closed across a fork. But there must be a reason, and I just don't have time to look at it now :-( If it is possible, I think we should preserve kqueue fd's across forks... It follows POLA. christos
Attachment:
signature.asc
Description: Message signed with OpenPGP