Looking for tcsh binary which uses vfork

[Chris Torek]

In article <783 at eplunix.UUCP> das at eplunix.UUCP (David Steffens) writes:
>Take a simple pipe: ``ls | more''.  If the 1st process (ls) finishes
>_before_ the 2nd process (more) is completely setup, then one gets
>the "Stopped (tty ouytput)" message, otherwise not.
>
>In terms of the source, the palloc() needed to associate the ``more''
>process with the job has not been done by the time that the ``ls''
>process finishes.  Then the wait loop in pwait() thinks the _whole_ job
>is done and steals the tty out from under the ``more'' process.
>Now the ``more'' process gets to run and set itself up, but too late!
>This isn't possible w/ vfork because the child _always_ gets to run 1st.

This explanation does not hold up, because vfork() does not change this.
Csh (and therefore tcsh) must, and presumably does (since it works now),
hold SIGCHLD during job creation.  If it did not, the following sequence
would be possible:

	csh: vfork
		child: set up tty pgroup, etc
		execl("ls")
	csh: resume; stash process for pwait()
	<here csh runs out of its scheduled cpu and gets bumped>
	ls: read dir, print, exit
	<now csh gets resumed>
	csh: take signal; pwait() `takes' the whole job

so vfork() would not prevent the same problem.  As long as SIGCHLD is
held, however, we have

	csh: fork
	csh: stash process for pwait	|	child: set up tty pgroup
					|	execl("ls")
	csh: fork			|	ls: read, etc
					|	ls: <exit>
	csh: (parent) signal held	|	csh: (child) execl("more")
	stash process for pwait		|
	release signal			|	more: <run>
	take signal, consume
		ls exit status;
		continue waiting
		for rest of pipeline

Here the actual order of things happening in the child process is
irrelevant (provided, of course, that one fixes the tty pgroup race).
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris at mimsy.umd.edu	Path:	uunet!mimsy!chris