On Fri, Jan 29, 2021 at 11:22:40PM +0100, Roland Illig wrote: > > 1. spurious waitpid > > > > when doing buildkernel I counted the following: > > 7010 cases of error code 0 (== nothing to do) > > 371 cases of ECHILD > > 1526 cases of reaping > > I'm not familiar enough with waitpid, so I will not touch this topic. > Simon?
wait is pretty basic unix :-p not sure what if anything I should explain... Anyway the issue here is that make already has at least two ways to know whether there's anything to wait for: first (at least in jobs mode) it will get EOF on the child's output pipe, and second, it also catches SIGCHLD. It might be necessary to try waiting a second time, because it might not be able to know how many children have exited (depends if they all trigger some EOF or just most of them) but it should not need to blindly call waitpid every time through the main select/poll loop. Right now the SIGCHLD handler works by writing into a pipe that the main loop polls, which is pretty grotty. It shouldn't need to do anything other than set a global (of type sig_atomic_t, to be portable) to 1. The delivery of a signal should cause all select and poll variants to fail with EINTR (that is, stop for attention) even if nothing else is pending. It's possible that it doesn't need the SIGCHLD handler at all; if every exiting subprocess triggers some EOF, the event loop will always wake up and make can know from the EOF reporting that it should call wait. However, this might make it harder to share code between jobs mode and non-jobs mode, since in non-jobs mode it's definitely not the case that every subprocess has a pipe. (I'm not sure how much of the jobs/non-jobs copypasting you've cleaned up lately, if any, since I'm way behind on reading the diffs.) -- David A. Holland dholl...@netbsd.org