job control
Moderator, John Quarterman
std-unix at ut-sally.UUCP
Tue Oct 7 09:15:47 AEST 1986
From: pyramid!utzoo!henry at sally.utexas.edu (Henry Spencer)
Date: Sat, 4 Oct 86 03:03:30 PDT
After some activity back when the Unix standard was with /usr/group, I've
"gone dormant" on standardization work through lack of time. I haven't
even seen most of the P1003 stuff. However, I understand that there is
a proposal to incorporate Berklix-like "job control" into P1003. Given
the interest in getting some new topics into mod.std.unix, I'm submitting
the following. It's a slightly touched-up version of a paper Ian Darwin
and I submitted to the /usr/group standards effort, arguing strongly that
neither 4BSD "job control" nor SysV "shell layers" should be incorporated
into a standard. Since I haven't seen the detailed P1003 proposal, it's
possible that some of this is out of date, but on the whole I think it's
of interest nonetheless.
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,decvax,pyramid}!utzoo!henry
[ Perhaps whoever has the original online copy of the current P1003
proposal could submit it? That would probably be worthwhile even if
it had to be broken into several articles for space reasons. -mod ]
Comments on Terminal I/O, Specifically `Job Control'
Henry Spencer
University of Toronto
utzoo!henry
Ian Darwin
University of Toronto
utcsstat!ian
`Job Control', What It's Really About
There is no longer any argument that it is desirable to permit orderly
user interaction with multiple processes. Unfortunately, a whole generation
of Unix users has had their view of this concept warped by the dreadful way it
was implemented by Berkeley. And AT&T, in its recent attempt to address the
problem, has taken the easy way out instead of doing it right.
The basic concept involved here is multiplexing, not `job control' or
process suspension. The ideal is something like the environment on the Bell
Labs Blit, where multiple processes run simultaneously in multiple windows,
and the user can switch his attention and his interaction from one to another
at will. There is a popular misconception that doing this *requires* a Blit
or a similar highly-intelligent terminal; this is simply not true.
Window-based multiplexed interaction is harder to do when the terminal is
dumb, but even the Blit is not actually writing things into several windows
*simultaneously*: it just looks that way because of the high-speed multiplex-
ing involved. There is no intrinsic reason why this multiplexing cannot be
done at the other end of the communications line when the terminal is incapa-
ble of doing it.
The multiplexing can be done in the kernel (albeit at considerable cost
in added kernel complexity) or in a user process (given suitable interprocess
communication). In either case, the fundamental structure is quite simple: a
central `manager' coordinates terminal i/o to and from `client' processes,
each of which has total control of its own "virtual terminal". The manager's
job is simulating multiple virtual terminals on a single real terminal, by
routing input to the appropriate process and placing output in the appropriate
area of the screen.
- 2 -
The basic characteristics of such a multiplexing system are that each
process has what looks (to it) like a private terminal, and that all i/o to
and from the user is centrally supervised. This is precisely analogous to
file i/o under Unix: simultaneous independent activity by multiple processes,
coordinated by a central manager which multiplexes physical resources so as to
prevent interference. The benefits are similar: individual processes neither
know nor care about the multiplexing, and useful high-level abstractions can
be implemented in one central place.
Job Control and Layers: Half-Baked Approaches
The existing schemes, Berkeley `job control' and AT&T `layers', unfor-
tunately are clumsy and incomplete attempts at implementing multiplexed
interaction. Neither one makes any provision for simultaneous on-screen
activities by more than one process, except for the `cop-out' of permitting
multiple processes to intermix their output at random. But there are deeper
problems.
Both schemes require that *every* *program* which is going to participate
in multiplexed interaction must contain code to allow for this possibility!
User programs must be prepared to redraw the screen on request, with the
requests coming from the kernel in the Berkeley scheme and from the user in
the System V.2 scheme. This is an abomination.
Not only does this demand specialized code in every user program, but it
entirely denies multiplexed interaction to the bulk of Unix programs. The
concept of `redraw the screen' is meaningful only for interactive programs
with full-screen interfaces. The result of, say, an *egrep*, once replaced
on-screen by (say) the editing buffer of a *vi*, is gone for good. Since
*egrep* is not an interactive program, it is no longer around to be asked to
redraw its output.
The heart of the problem is that neither job control nor layers imple-
ments the crucial half of a window system: centralized management of screen
updates. It has long been accepted that multiple processes cannot safely do
updates to disks without centralized management and consistency control. The
same obviously applies to terminal i/o: orderly simultaneous interaction with
multiple processes requires centralized supervision of the interaction. The
existing schemes supervise input but not output.
It is obvious *why* this deficiency exists: supervising output is the
hard part. The idea of switching input from one program to another is reason-
ably straightforward. Differences in input handling, such as `cooked' vs.
`raw' modes, are relatively minor problems, since the user can be conversing
with at most one process at a time. But a CRT terminal permits output from
multiple processes to be displayed simultaneously, and coordinating screen
updates isn't trivial. Furthermore, there is no agreement on the precise user
interface that should be presented for output -- consider, for example, the
religious debates over overlapping vs. non-overlapping windows -- and this
discourages attempts to provide a single and relatively inflexible central
solution. The immense variation in CRT-terminal control sequences puts the
icing on the cake.
- 3 -
Nevertheless, these problems *can* be solved. There are at least three,
and probably several more, complete window systems in experimental use. Some
of them have performance problems, and most of them are outside the kernel and
hence have interprocess-communication problems, but they do work.
Standardizing Multiplexed Interaction: A Recommendation
As mentioned above, several experimental window systems already exist.
(This is quite apart from the `real' window systems on bitmapped workstations,
which are also relevant.) Experience with these and other implementations of
the same concept will yield a wealth of knowledge on how best to handle this
function. It is important that this experimentation, and the adoption of the
results that come out of it, not be stifled by further `official endorsement'
of incomplete and badly-designed existing schemes.
The best approach for P1003 to take on this matter would be to reserve
some characters, and some flag bits, for implementations of multiplexed user
interfaces, but not to specify any such interface at this time. Such an
attempt to specify the interface would be premature, especially when the two
approaches under consideration are already known to be grossly-incomplete
botches.
*Neither Berkeley `job control' nor AT&T `layers' is an adequate imple-
mentation of a multiplexed user interface*. *Neither one should be cast in
concrete as a standard at this time*.
A Retraction
Our previous recommendation was that, if multiplexed interaction *must*
be standardized, AT&T `layers' would be a better place to start. The layers
system, unlike Berkeley job control, does do input multiplexing more-or-less
correctly, and hence is essentially upward-compatible with true window sys-
tems. It has several desirable characteristics: independent tty state for
each layer, suspension/resumption invisible to the processes, a central
manager process which is *not* imbedded in a shell, and an implementation that
does not have ramifications everywhere.
Nevertheless, as discussed above, it doesn't do the hard part: output
multiplexing. It also has some annoying implementation limits, which,
although they wouldn't necessarily have to propagate into a standard, might
well propagate into most early implementations. Its major problem is that
it's not clear how to extend it to centralized output management without
imbedding said management inside the kernel.
We therefore retract our recommendation for standardizing layers as a
second choice. The proper course is to standardize nothing, at least until we
understand the user-interface issues and the implementation problems better.
Specifics
A decision not to standardize a multiplexed-interaction scheme notwith-
standing, there are a few useful minor things that can be standardized. The
*termio* structure probably should have a reserved character or two (or room
for same) and a few reserved bits (or room for same) to permit kernel-based
- 4 -
implementations of multiplexing.
In particular, almost any multiplexing scheme using ordinary ASCII termi-
nals will need a special character to attract the attention of the multiplex-
ing software. Without this, it's very difficult to do things like moving
between windows. Reserving space for such a character might be useful; recom-
mending a default choice for the character would be very valuable, as it would
forestall unnecessary differences between implementations. Control-Z would be
plausible.
Implementing supervision of multiplexed interaction in user processes is
difficult in many existing Unix implementations, minimal implementations of
the existing P1003 standard among them. The basic problem is that normal user
processes are definitely aware that their output is going to a terminal, the
device-independence of Unix i/o notwithstanding. Screen-oriented programs
doing *ioctl*s are the biggest problem. A less obvious glitch is that *stdio*
adjusts its buffering strategy depending on whether output is to a terminal or
not; this is a major nuisance with some existing window systems. Something
like the `pseudo-tty' concept would be very useful: an entity which looks
like a terminal from one side, but whose behavior is under user-process con-
trol from the other side. Some existing systems do implement such things, but
the lack of standardization largely prevents use of them in portable programs.
Suspending Processes: A Non-Issue
Several people have objected to AT&T layers, and similar approaches, on
the grounds that `...but 4BSD lets me suspend misbehaving processes...'. This
is silly; a process-suspension facility can be very simple if it isn't
required to double as a multiplexing system.
If it is thought desirable to standardize process suspension, we would
suggest the following. Some magic character (control-Y?), when typed as input
to a tty/window, suspends all processes attached to that tty/window. The
suspension can be, and should be, utterly invisible to the processes involved.
This avoids the sticky problem of how to notify the processes without doing
incompatible things to the *signal* mechanism. The suspension probably should
have a permission requirement analogous to that of signals: if the effective
userids of the user and the process don't match, the suspension doesn't hap-
pen. This is necessary to prevent major security breaches like suspending
*passwd*(1) in the middle of an update to the password file.
Note that this suspension facility isn't very useful in the absence of
multiplexed interaction -- you can't *do* anything to a suspended process
without access to another (real or virtual) terminal -- but the two concepts
are nevertheless quite independent. There is no need to confuse them.
Volume-Number: Volume 7, Number 30
More information about the Mod.std.unix
mailing list