Re: [gentoo-portage-dev] [RFC/PATCH] prepstrip/ecompressdir: parallelize operations

[Brian Harring]

On Mon, May 14, 2012 at 09:33:58AM +0200, Michael Haubenwallner wrote:
>
>
> On 05/11/2012 06:39 PM, Mike Frysinger wrote:
> > +multijob_child_init() {
> > +	trap 'echo ${BASHPID} $? >&'${mj_control_fd} EXIT
> > +	trap 'exit 1' INT TERM
> > +}
>
> Just wondering why $! in parent isn't used anywhere, even not for some
> integrity check if the child's BASHPID actually was forked by parent.

wait'ing on it can fail; roughly bash basically reaps on it's own 
(uncontrollably so), but bash still will actually do the wait, 
basically falling back to it's internal list of what it reaped.

That's *roughly* what I got out of it when I wrote what vapier's 
ape'ing here, and is exactly the issue that bit me in the ass on a 48 
core.  If things are moving fast enough, sooner or later that whacky 
wait behaviour will intersect a real pid, one that isn't a direct 
child, and bash will puke a horrible error.

That pretty much leaves you w/ 'wait jobspec' or 'wait' to clean up 
the bash innards.  This exact issue is why the code passes the exit 
status back.

~harring