Path: utzoo!mnetor!uunet!vsi!friedl
From: friedl@vsi.UUCP (Stephen J. Friedl)
Newsgroups: comp.unix.wizards
Subject: Re: SVR3.0 vs BSD4.3
Message-ID: <445@vsi.UUCP>
Date: 25 Mar 88 06:31:38 GMT
References: <12414@brl-adm.ARPA> <4361@megaron.arizona.edu> <7499@brl-smoke.ARPA> <7542@brl-smoke.ARPA>
Organization: V-Systems, Inc. -- Santa Ana, CA
Lines: 27
Summary: shell layers do not have signals

In article <7542@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes:
< In article <2050@munnari.oz> kre@munnari.oz (Robert Elz) writes:
< >But that's not job control.  Job control is when I notice that /foobar
< >is 98% full, and some cretin has a job running that's half way through
< >extracting 160Mb from a tar tape .. "kill -STOP <pid>" is job control.
< 
< Most 4BSD job control seems to be done by typing ^Z, "fg", "bg", etc.
< Running under "shl", there is a keyboard-generated signal similar to
< TSTP and analogs of fg, bg, etc.  That is why I said that "shl" is
< the AT&T UNIX equivalent of 4BSD job control.  As both of us have
< said, each approach has advantages and disadvantages w.r.t. the other.

Shell layers do not involve any kind of signals.  When ^Z is hit,
the sxt driver gives control back to channel zero, which is
usually the layer manager (here, /usr/bin/shl).  When a user
command to shl asks that a child layer be run, the layer manager
issues an ioctl to the multiplexor to give control to the child's
layer (there is no SIGCONT).  One result of this implementation
is that I know of no way for a layer to suspend itself, certainly
not with signals (if anybody else knows how I would love to hear it).

Nevertheless it is not incorrect to equate job-control with shell
layers in a general kind of way -- kre's way just may be more general
than mine :-).
-- 
Steve Friedl      V-Systems, Inc.        *Hi Mom*
friedl@vsi.com   {uunet,attmail,ihnp4}!vsi!friedl