From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-workers-request@math.gatech.edu>
Received: (qmail 25174 invoked from network); 18 Apr 1998 19:37:52 -0000
Received: from math.gatech.edu (list@130.207.146.50)
  by ns1.primenet.com.au with SMTP; 18 Apr 1998 19:37:52 -0000
Received: (from list@localhost)
	by math.gatech.edu (8.8.5/8.8.5) id PAA17508;
	Sat, 18 Apr 1998 15:15:58 -0400 (EDT)
Resent-Date: Sat, 18 Apr 1998 15:15:58 -0400 (EDT)
From: TGAPE! <tgape@cyberramp.net>
Message-Id: <199804181321.NAA12785@dal-tsa21-41.cyberramp.net>
Subject: Re: Pipeline process wait bug in 3.0.5
To: zsh-workers@math.gatech.edu
Date: Sat, 18 Apr 1998 13:21:34 +0000 (GMT)
In-Reply-To: <980418030434.ZM3820@candle.brasslantern.com> from "Bart Schaefer" at Apr 18, 98 03:04:34 am
X-Mailer: ELM [version 2.4 PL25]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"oda2Q3.0.SH4.jlFEr"@math>
Resent-From: zsh-workers@math.gatech.edu
X-Mailing-List: <zsh-workers@math.gatech.edu> archive/latest/3844
X-Loop: zsh-workers@math.gatech.edu
Precedence: list
Resent-Sender: zsh-workers-request@math.gatech.edu

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