V.2 Job Control

[Guy Harris]

> 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.

That's one reason I don't think that the S5R2 "job control" is really
100% job control.  The Berkeley job control serves two functions; 1) it
is sort of a facility for supporting multiple active tasks - sort of a window
manager without windows and 2) it permits you to suspend jobs and resume
them later.  The suspension and resumption of 2) is used to provide the
functionality of 1), but a true window manager provides 1) in a more convenient
form.  However, as you and others have pointed out, the functionality of 2)
is useful on its own.

As has been mentioned before, the problem with the S5R2 "job control" as a
window manager is that more information has to be stored on a per-virtual-
terminal basis than just the ioctl-controlled modes.  The Berkeley approach
requires the program to save and restore this information (screen contents,
terminal modes, etc.); usually the program can compute this information
far more easily than a window manager can reconstruct it by monitoring all
characters sent to/from the terminal, so the Berkeley approach makes it
easier to provide this sort of multiplexing.

	Guy Harris
	{seismo,ihnp4,allegra}!rlgvax!guy