Pipeline process wait bug in 3.0.5

Pipeline process wait bug in 3.0.5

[Bart Schaefer]

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.

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

Re: Pipeline process wait bug in 3.0.5

[TGAPE!]

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

Re: Pipeline process wait bug in 3.0.5

[Bart Schaefer]

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