RE: I disabled more compiler warnings..

[David Laight <David.Laight@ACULAB.COM>]

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)