Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!alice!dutoit!dmr
From: dmr@dutoit.UUCP
Newsgroups: net.unix-wizards
Subject: Job control
Message-ID: <2113@dutoit.UUCP>
Date: Sat, 12-Apr-86 04:10:44 EST
Article-I.D.: dutoit.2113
Posted: Sat Apr 12 04:10:44 1986
Date-Received: Mon, 14-Apr-86 06:08:35 EST
Lines: 76

Here are a few thoughts about windows, job control, and elegance vs.
hackery.

It seems to be granted by everyone that windows, especially on good
terminals, are desirable, and there is consequently some boasting and
envy on the part, respectively, of the haves and have-nots.  These
feelings are real, but unrelated to the technical considerations.

The inherent advantage of a window system, on a suitable terminal, over
job control is that it lets you have spatial separation of several
independent conversations.  On an ordinary text terminal, the windows
are perforce either very small (as in emacs, for example) or are
time-multiplexed on one screen (as in BSD and also AT&T job control).
Otherwise, though, the two notions share much, and similar approaches
to them can be useful.

The underlying problem that has to be solved in the system and the
user-level software is how to manage the several separate computations
and their IO.  BSD job control does this by pushing hard on the idea of
process groups: separate jobs have different process groups, and the
various drivers check flags that get set by signals sent to the
appropriate group.  In this way, job groups have their IO and CPU
demands controlled so that they don't interfere on the screen.  This is
orchestrated by special coding in csh.  All the jobs are talking to the
same terminal.  The total amount of code in the kernel is not terribly
large, but it is spread widely and much of it is frank special pleading
(E.g. the comment in sig.c:  "Children of init aren't allowed to stop
on signals from the keyboard" annotating code that turns SIGTSTP,
SIGTTIN, and SIGTTOU into SIGKILL if the parent is process 1.  This
from 4.1.)

In the Eighth Edition and also in the System V shl mechanism, each job
communicates with one of a set of virtual devices multiplexed onto the
real device.  In SV the multiplexor is in the kernel and is quite
simple; mainly it just blocks IO from background jobs.  In V8 it is a
user-level program that talks to an educated terminal.  In SV with 5620
support, the multiplexor is again a kernel program similar to that used
by shl (though the the multiplexor is more complicated because it
speaks in protocol to the terminal).  In none of these is a special
shell needed.  The virtual terminal seen by each job has its own
instance of the tty driver; for example, you can turn off echo in one
job (or window) without affecting another.  Of course, neither shl, nor
BSD job control, knows anything about the real terminal: what is on
the screen or any special modes the terminal itself might be in.

How should we judge these offerings?  It seems to me that the the V8
and the SV mechanisms are cleaner because they create a more natural
separation between independent jobs than having a particular shell
scatter lightning bolts in the form of signals and process group
manipulation.  They generalize better, and they provide the service
less clumsily: shl is a pseudo device driver, and the V8 implementation
falls automatically out of its IPC.

However, conceptual superiority doesn't guarantee that the effect will
be better.  The mutterings over SIGTSTP start to show this.  It seems
perfectly plausible that a signal should be available to a program that
might want to redraw its screen when its job was unblocked or window
reshaped, and there was nothing preventing shl from generating it.

In theory, BSD job control is much more of a wart on the system than
the SV shl idea.  In practice, provided that you are willing to use
csh, or more recently ksh (and I'm not), the BSD scheme is easier to
use.  It is always there, at the touch of a key, and it works.

My impression is that BSD job control is something that was
put in by expedient means in order to achieve a certain effect, and the
effect is excellent, within the serious limitations of the mechanism.
SV job control was done with a cleaner conceptual foundation, but with
a less lucid view of what it is for, and less effort devoted to making
it useful. Indeed, I suspect it is not much used.  For example, on the SV
machines run by the local comp center, shl is available, but doesn't
work (it hangs your terminal) when you come in via the network instead
of a dial-up or hard-wire.


	Dennis Ritchie