Re: Pipeline process wait bug in 3.0.5

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxx>]

On Apr 18,  1:21pm, TGAPE! wrote:
} Subject: Re: Pipeline process wait bug in 3.0.5
}
} Bart Schaefer wrote:
} > 
} > isset () {
} >         setopt | grep -i $(echo $1 | tr -d _)
} >}
} > 
} > However, a bit less than half the time, running this function produces
} > 
} > zsh% isset autocd
} > zsh% autocd                on
} 
} I'm not certain, but this seems related to the 'night of the living dead
} (processes)' problem I reported a while back.  At least, I predicted
} this type of occurance when I heard the description of what my problem
} was.  Basically, only one process in the pipeline gets waited on.

Hmm.  I do recall that thread; but if this is related, it's because the
-wrong- process is getting waited on, I think ...

execpline2() in exec.c forks builtins and functions when they're on the
left side of a pipeline, and adds them to the job table.  It then calls
itself recursively on the right side of the pipe, which forks again to
run the external command and adds it to the job table as well.  Zsh does
eventually call some form of wait() [*] for everything that's in the job
table, so nothing's getting left to init in a simple pipeline like this.

However, if I'm reading addproc() correctly, the builtin has already been
made the process group leader.  My guess is that setopt doesn't produce
enough output to fill the kernel buffer for the pipe from it to grep, so
the LHS of the pipe runs and exits before the RHS even gets started.  At
this point I lose track of what's going on ... I think what happens is
that zsh end up waiting only for the group leader [*] and thus comes out
of waitjob() before the grep has finished.

Is the fix for this simply to set STAT_SUPERJOB sooner, for any pipeline,
rather than setting it only for those that've been stopped with ^Z and
that only after they've stopped?

[*] Zsh actually calls wait() via the WAIT() macro in the SIGCHLD handler.
What waitjob() does is wait for a SIGCHLD and then loop if the desired job
hasn't finished.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com