V.2 Job Control

[tjt at kobold.UUCP]

Well, I'm willing to take a crack at answering omsvax!plb's questions.
Keep in mind that I don't know anything about the System V.2 job
control aside from what was presented at USENIX.

I also had the impression that the virtual terminals ("layers")
implemented by the V.2 job control are very close to a primitive window
manager.  This has one major advantage over the Berkeley job control,
and one major disadvantage.  The advantage of using virtual terminals
(as was pointed out) is that no process ever has to worry about whether
it has control of the terminal when it wants to change terminal modes:
each virtual terminal has its own copy of the terminal mode.

The major disadvantage is that there is no way to suspend a process.
It is often useful to suspend e.g. a CPU intensive process such as
nroff or a c compile if your system is sluggish but you don't want to
kill the whole job.

However, the lack of some sort of signal to indicate that a job is in
the foreground and should repaint the screen is a major omission.  A
good window manager will do this automatically. i.e. save the raster
image when a window gets covered up, and restore the image when the
window gets pulled to the top (or front, if you prefer).  A window
manager will usely let you catch a signal when you get obscured and/or
pulled to the front if you want to do something fancier.

The Berkeley job control may handle terminal modes and continue signals
in a somewhat kludgy manner, but since there is nearly a one-to-one
correspondence between programs that change terminal modes and programs
that want to repaint the screen when they resume.  The remaining
programs that change the terminal mode generally switch to raw mode and
therefore do not require any change: it is impossible to wrest control
away from the process without its cooperation (it will ignore ^Z unless
it has been trained to recognize it).

The final feature of a window manager that appears to be missing from
the System V.2 job control is the apparrent lack of a "top level"
window manager.  I say "appears" because this was not clear (to me, at
least) from the talk.  A window manager has some inescapable way of
taking control of the keyboard/mouse from the current virtual terminal
(window) so that a new virtual terminal (window) can be created or
selected.

Actually, I guess that this is what ^Z does in the System V.2 job
control, but you have to be careful to never execute anything directly
from your top level shell (except shl commands) since your top level
shell *is* your window manager.  Of course, if you do this you lose the
ability to keep a common history sequence for all your jobs.  In
addition, in BSD you have the "jobs" command, and with a BLIT (or
similar terminal) you have the visual display of all those windows to
tell you whats going on.  I don't remember what facilities there were
for keeping track of blocked "layers".

Anyway, I think the V.2 job control is at best, a near miss.  However,
the same basic functionality *as part of a window manager* is probably
sufficient.  At MIT, the Nu terminals did not have job control but were
able to get by quite nicely using a window manager.  I don't think this
would be acceptable without automatic window refresh.
-- 
	Tom Teixeira,  Massachusetts Computer Corporation.  Westford MA
	...!{ihnp4,harpo,decvax}!masscomp!tjt   (617) 692-6200 x275