Re: Pipeline process wait bug in 3.0.5

[TGAPE! <tgape@cyberramp.net>]

Bart Schaefer wrote:
> 
> I have this little function:
> 
> isset () {
>         setopt | grep -i $(echo $1 | tr -d _)
>}
> 
> This is so I can type e.g.
> 
> zsh% isset auto_cd
> autocd                on
> 
> However, a bit less than half the time, running this function produces
> 
> zsh% isset autocd
> zsh% autocd                on
> 
> (with the cursor now at the beginning of the next line).  I can't be sure,
> of course, but it seems to me this must be a problem with zsh failing to
> wait for the entire pipeline to complete before it prints the next prompt.

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.

My problem was I was doing some intense loops with excessive pipelining
(I tend to use that as my omni-hammer, even when it doesn't always make
sense...) which was sending thousands of processes to init; init's
inefficient handling (it has to reload /etc/inittab each child) caused
it to virtually spin.

It was explained to me that it saves on number of pids on the system,
but considering how poorly init handles zombies, I don't think it's a
practical way to handle that, especially on systems like Linux which
fork using copy-on-write pagemarkings.  However, I've not had the time
to make a patch for it.

Ed