Re: bmake inefficiencies

[David Holland <dholland-current%netbsd.org@localhost>]

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
dholland%netbsd.org@localhost