From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-workers-request@math.gatech.edu>
Received: (qmail 25812 invoked from network); 18 Apr 1998 22:09:04 -0000
Received: from math.gatech.edu (list@130.207.146.50)
  by ns1.primenet.com.au with SMTP; 18 Apr 1998 22:09:04 -0000
Received: (from list@localhost)
	by math.gatech.edu (8.8.5/8.8.5) id RAA18768;
	Sat, 18 Apr 1998 17:50:32 -0400 (EDT)
Resent-Date: Sat, 18 Apr 1998 17:50:32 -0400 (EDT)
From: "Bart Schaefer" <schaefer@brasslantern.com>
Message-Id: <980418144956.ZM5045@candle.brasslantern.com>
Date: Sat, 18 Apr 1998 14:49:56 -0700
In-Reply-To: <199804181321.NAA12785@dal-tsa21-41.cyberramp.net>
Comments: In reply to TGAPE! <tgape@cyberramp.net>
        "Re: Pipeline process wait bug in 3.0.5" (Apr 18,  1:21pm)
References: <199804181321.NAA12785@dal-tsa21-41.cyberramp.net>
X-Mailer: Z-Mail (4.0b.820 20aug96)
To: zsh-workers@math.gatech.edu
Subject: Re: Pipeline process wait bug in 3.0.5
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Resent-Message-ID: <"599CA2.0.Bb4.e0IEr"@math>
Resent-From: zsh-workers@math.gatech.edu
X-Mailing-List: <zsh-workers@math.gatech.edu> archive/latest/3845
X-Loop: zsh-workers@math.gatech.edu
Precedence: list
Resent-Sender: zsh-workers-request@math.gatech.edu

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