Messages in this thread | | | From | David Laight <> | Subject | RE: I disabled more compiler warnings.. | Date | Wed, 13 May 2020 15:53:43 +0000 |
| |
From: Paul Smith > Sent: 13 May 2020 16:33 > On Wed, 2020-05-13 at 08:21 +0000, David Laight wrote: ... > If we don't have pselect() we use the close() in the signal handler. > In that case we're just waiting in the read(), we're not using select() > or poll() or whatever. It's definitely the case that if we're waiting > in read() and someone closes the FD, we'll wake up! :)
Ugg, that is relying on getting either EINTR or EBADFD. I can't remember if Posix allows SIGCHLD to be delivered in a different thread. Windows definitely likes delivering signals that way :-)
> > > 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. > > Right, my first idea has this same problem so it won't work. > > > Actually the token pipe can be opened NON_BLOCK because poll() > > can/will be used to wait for a token. > > Again, that only works on systems where pselect() is available. > > > 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. > > Something like that would be needed, yes. > > Note this is only needed in a rare situation where you're running with > parallelism enabled BUT you have a makefile which never actually tries > to run two or more jobs at the same time for some reason.
I did have to recirculate the tokens. Can't exactly remember why.
David
- Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
| |