Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site kobold.UUCP Path: utzoo!watmath!clyde!floyd!harpo!eagle!mit-vax!grkermit!masscomp!kobold!tjt From: tjt@kobold.UUCP Newsgroups: net.unix-wizards Subject: Re: V.2 Job Control Message-ID: <267@kobold.UUCP> Date: Wed, 1-Feb-84 20:22:50 EST Article-I.D.: kobold.267 Posted: Wed Feb 1 20:22:50 1984 Date-Received: Wed, 8-Feb-84 02:28:17 EST References: <794@omsvax.UUCP> Organization: Masscomp, Westford, MA Lines: 60 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