transferring processes under csh

[Rick Ace]

In article <235 at longway.TIC.COM>, jsq at longway.TIC.COM (John S. Quarterman) writes:
> In article <2364 at pixar.UUCP> rta at pixar.UUCP (Rick Ace) writes:
> ...
> >Roadblocks to making ATTACH work under UNIX:
> >1. UNIX has no formal concept of a "job"
> 
> Actually, it does:  the process group.  Csh uses it all the time in
> job control.

The UNIX process group is not analogous to the TOPS-20 job.
Perhaps my statement should be rephrased to read, "UNIX has no
formal concept analogous to the TOPS-20 job."

> >   (This is not the only approach, but it worked well for ATTACH.)
> 
> Actually you attach to the session, not the job.

No, you attach to the job.  TOPS-20 does not have "sessions".

> >3. Processes have direct handles (file descriptors) on terminals;
> >   they do not go indirect a job-common location.  About the
> >   closest thing to a "controlling terminal" is /dev/tty, but
> >   that's not what you'll find at stdin/stdout/stderr.
> 
> Ah, but both System V and BSD have controlling terminals.
> Try looking at vhangup(2) in BSD or setpgrp(2) in System V.

Whoa!  Don't look at vhangup(2) immediately after eating food.
It only does half the job (removing access to open file descriptors
to the specified tty) and it does it half-baked at that:

	1. background process A does read(2) or write(2) to tty
	   and gets put to sleep in tty.c
	2. vhangup(2) gets called
	3. process A unblocks and continues to read from or scribble on
	   tty device after vhangup has revoked authorization

The other half of the job, namely executing the line-discipline and
driver "close" routines, is not guaranteed to happen when vhangup
is called.

In short, vhangup is an expedient solution to a problem that should
rightfully be solved by a revision of the design of terminal ownership
and session semantics under UNIX; it is hardly valuable as an
illustration of anything other than that.

Rick Ace
Pixar
3240 Kerner Blvd, San Rafael CA 94901
...!{sun,ucbvax}!pixar!rta