On Fri, Aug 18, 2006 at 06:35:58PM +0200, Quentin Garnier wrote:
> On Fri, Aug 18, 2006 at 06:18:27PM +0200, Frank Kardel wrote:
> [...]
> > I don't think we are on the right track here.
> > One thing that puzzles me is that make apparently complains
> > about childs it does not know about. My understanding of Unix
> > principles is that SIGCLD and/or the wait-results is either
> > delivered to the immediate parent or init in case a process is orphaned.
> > That means make must have forked the childs it claims to know nothing
> > about. I cannot see how a sub-make(/process) could fork processes where the
> 
> In that case, no.  make forks sh to run sets.subr, which in turns forks a
> make process.  File-descriptors are kept open all along (it's probably part
> of the problem, although the child make would complain in turn if the fds
> were closed and still it got -J).

The complaint is silent - it is under '#if 0'.
If the fds are closed, the child make uses the -j n argument to start another
'n' programs, with a different token pipe.  You don't want this to happen.

I also (think) I've run that part of the build with make erroring out
if the token pipe was closed - and it didn't fail building the scripts.

make's job list processing is horrid, it fakes up calls to its own
signal handler for 'job start' events.  I've a plan to rewrite it using
an array with one slot per job (sized from the -j n parameter) so that
almost all the signal interlocks can be removed.  If nothing else that
will save 1000s of system calls.

But I need another round tuit.

	David

-- 
David Laight: david@l8s.co.uk