Usenet 1994 January/usenetsourcesnewsgroupsinfomagicjanuary1994.iso/sources/std_unix/mod.std.unix.v7/text0029.txt

Internet Message Format | 1987-06-30 | 12.6 KB

From: pyramid!utzoo![e-mail]  (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