Newsgroups: comp.os.minix
Path: utzoo!henry
From: henry@utzoo.uucp (Henry Spencer)
Subject: Re: job control is a bug, not a feature
Message-ID: <1989Jun8.172420.27288@utzoo.uucp>
Organization: U of Toronto Zoology
References: <16497@louie.udel.EDU> <11989@bcsaic.UUCP> <2775@munnari.oz> <798@gara.une.oz> <8167@boring.cwi.nl> <1989Jun7.224933.700@utzoo.uucp>
Date: Thu, 8 Jun 89 17:24:20 GMT

In article <1989Jun7.224933.700@utzoo.uucp> I wrote:
>If anyone is interested, I think I still have the scathing commentary on
>job control that Ian and I did at the time.

I'm already getting a steady stream of requests for this, so here it is.
If I were formally submitting it today I'd probably make some small changes,
but I don't have time for that now (so bear in mind that it's old).  Also,
I have not consulted Ian about this and cannot say whether his views have
changed or not.

----------
.TL
Comments on Terminal I/O, Specifically `Job Control'
.AU
Henry Spencer
.AI
University of Toronto
utzoo!henry
.AU
Ian Darwin
.AI
University of Toronto
.SH
`Job Control', What It's Really About
.PP
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.
.PP
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 \fIrequires\fR a
Blit or a similar highly-intelligent terminal;
this is simply not true.
.PP
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 \fIsimultaneously\fR:
it just looks that way because of the high-speed multiplexing involved.
There is no intrinsic reason why this multiplexing cannot be done at
the other end of the communications line when the terminal is incapable
of doing it.
.PP
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.
.PP
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.
.SH
Job Control and Layers:  Half-Baked Approaches
.PP
The existing schemes, Berkeley `job control' and AT&T `layers',
unfortunately 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.
.PP
Both schemes require that \fIevery\fR \fIprogram\fR 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.
.PP
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 \fIegrep\fR, once replaced on-screen by (say)
the editing buffer of a \fIvi\fR, is gone for good.
Since \fIegrep\fR is not an interactive program, it is no longer around
to be asked to redraw its output.
.PP
The heart of the problem is that
neither job control nor layers implements 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.
.PP
It is obvious \fIwhy\fR this deficiency exists:  supervising output is
the hard part.
The idea of switching input from one program to another is reasonably
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 \(em consider, for example, the religious
debates over overlapping vs. non-overlapping windows \(em 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.
.PP
Nevertheless, these problems \fIcan\fR 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.
.SH
Standardizing Multiplexed Interaction:  A Recommendation
.PP
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.
.PP
The best approach for /usr/group 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.
.PP
\fINeither Berkeley `job control' nor AT&T `layers' is an adequate
implementation of a multiplexed user interface.
Neither one should be cast in concrete as a standard at this time.\fR
.SH
A Retraction
.PP
Our previous recommendation was that, if multiplexed interaction \fImust\fR
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 systems.
It has several desirable characteristics:
independent tty state for each layer,
suspension/resumption invisible to the processes,
a central manager process which is \fInot\fR imbedded in a shell,
and an implementation that does not have ramifications everywhere.
.PP
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.
.PP
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.
.SH
Specifics
.PP
A decision not to standardize a multiplexed-interaction scheme
notwithstanding, there are a few useful minor things that can be
standardized.
The \fItermio\fR 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 implementations of multiplexing.
.PP
In particular, almost any multiplexing scheme using ordinary ASCII
terminals will need a special character to attract the attention of
the multiplexing software.
Without this, it's very difficult to do things like moving between
windows.
Reserving space for such a character might be useful; recommending a
default choice for the character would be very valuable, as it would
forestall unnecessary differences between implementations.
Control-Z would be plausible.
.PP
Implementing supervision of multiplexed interaction in user processes
is difficult in many existing Unix implementations, minimal
implementations of the existing /usr/group 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 \fIioctl\fRs are the biggest problem.
A less obvious glitch is that \fIstdio\fR 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 control from the other side.
Some existing systems do implement such things, but the
lack of standardization largely prevents use of them in portable programs.
.SH
Suspending Processes:  A Non-Issue
.PP
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.
.PP
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 \fIsignal\fR 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 happen.
This is necessary to prevent major security breaches like suspending
\fIpasswd\fR(1) in the middle of an update to the password file.
.PP
Note that this suspension facility isn't very useful in the absence
of multiplexed interaction \(em you can't \fIdo\fR anything to a
suspended process without access to another (real or virtual) terminal \(em
but the two concepts are nevertheless quite independent.
There is no need to confuse them.
.SH
Miscellaneous Comments
.PP
Departing from multiplexed interaction, we'd like to raise again a
couple of minor issues mentioned in the previous paper...
.PP
An ignored hangup signal should not only cause reads to return
end-of-file,
it should also cause writes to be no-ops.
Hangup should, in general, disconnect lingering processes from the
terminal completely,
so they don't hang around to bedevil the next user.
.PP
One extremely useful feature that is missing is terminal pagination.
To quote Rob Pike:  ``terminals should not scroll [without
the user's permission]''.
Many people think this a useless frill, but they almost invariably
are people who have never tried it.
Most people who try it seriously, love it.
Even the simplest and crudest implementations (such as the one on the
system this document is being written on) are major improvements on
a terminal interface that lacks this feature.
This is not a new and unknown idea:  it has been conceived and implemented
independently at least three times, has been in use for years, and is
generally perceived by its users as a big win.
----------
-- 
You *can* understand sendmail, |     Henry Spencer at U of Toronto Zoology
but it's not worth it. -Collyer| uunet!attcan!utzoo!henry henry@zoo.toronto.edu