Phillip Wood <phillip.wood123@xxxxxxxxx> writes: >> An obvious disadvantage (at least of this implementation), is that it >> actually doubles the number of events that need to be handled for each >> children process on most cases (ex: when `poll()` gets interrupted) >> I suspect that if fixing that last race condition is so important >> with >> the current foundation, it might be better to reintroduce some sort of >> timeout to poll(), so that they will be cleared periodically. >> I had a prototype (only the bare minimum) that I thought was more >> efficient and that would instead remove completely the need for a >> signal handler which I would post (only for RFC) later. > > I'm not sure injecting an fd into each child process is a good direction. Yeah, I thought that the "self pipe trick" (in the title) refers to the technique to have a single pipe for the daemon to talk to itself, so that it can write(2) into the pipe in non-blocking way upon signal and expect its select/poll to be able to notice, where it can reap the completed children, so having a pipe per child was a surprise to me.
