From: Paul Smith > Sent: 12 May 2020 17:55 > On Tue, 2020-05-12 at 15:04 +0000, David Laight wrote: > > I think there were some sub-makes that were started with make > > instead of $(MAKE) so ended up creating a new job pipe. > > Oh, yes, that will do it. > > > Doesn't it do blocking reads with SIGCHLD enabled? > > No, because it's racy (by itself). > > > (or hopefully ppoll() to avoid the race) > > GNU make uses pselect(), on systems that support it. On systems that > don't support pselect() it uses a trick I described in another email: > we dup() the FD, read() on the dup, then in the SIGCHLD handler we > close() the dup.
Does that even work - seems like it requires close() to abort poll(). Better is to just have the SIGCHLD handler write a byte into a pipe. > > Another option is for the 'parent' make to return (or not acquire) > > a job token for $(MAKE) commands. > > It just feels cleaner to me to have the parent simply always take the > token, and leave it up to the child to put it back if appropriate, > rather than the parent putting it back. > > Having the parent not acquire a token at all won't work; without > limiting sub-makes it means you might have 100's of them running at the > same time, even with -j2 or whatever. Hmmm... That means the sub-make must always hold one token. Otherwise the parent-make could use it to create a new sub-make. Actually the token pipe can be opened NON_BLOCK because poll() can/will be used to wait for a token. So you always try to read a token - even when you have one 'in your hand' (either entry or because a job just finished). If it isn't the 'abort' one, put it back. A bit of faffing on the token pipe isn't going to affect the performance when it is about to do fork+exec. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)