Subject: Re: Warning popping up during -j builds
To: Frank Kardel <firstname.lastname@example.org>
From: Quentin Garnier <email@example.com>
Date: 08/18/2006 18:35:58
Content-Type: text/plain; charset=us-ascii
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 t=
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).
> grand parent gets to see the exit codes via wait(pid)(). Where did I miss
> something here ? I still have the impression that the job list handling m=
> be incomplete (unless, of course, make has pid 1 :-)). It may be that the
> forks happen at a(nother) place (e.g. library) where they are not=20
> entered in the job
> list. If that is the case (and can be proven), then we should get rid of=
> the message
> as it is of limited (and confusing) value if we are not able by design=20
> to catch all
> forked pids in the job list. If the joblist is definitely complete, we=20
> have a coordination
There's an issue somewhere, clearly, but otoh, no-one really bothered to
debug it in about three years.
Quentin Garnier - firstname.lastname@example.org - cube@NetBSD.org
"When I find the controls, I'll go where I like, I'll know where I want
to be, but maybe for now I'll stay right here on a silent sea."
KT Tunstall, Silent Sea, Eye to the Telescope, 2004.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (NetBSD)
-----END PGP SIGNATURE-----