P L Barrett@omsvax.UUCP (Donna Loveland) (01/31/84)
Well, a week or so has passed since UNIFORM (actually 11 days) and as yet I've seen nothing about the new V.2 job control stuff. Considering the reaction to the USENIX (oops, UNIFORM) talk on the subject I thought the net would be crackling with flames. (An aside, was I halucinating or were people REALLY booing the presenter?) Anyway, my questions: 1) It looks like I'd have to decide in ADVANCE if I'm going to use job control. Is this true? Tell me I'm wrong. (All I have to go on is the talk and a document that got passed around here.) 2) Does the 'controlled' process (ie the one being 'suspended') block on standard I/O or immediatly? I suspect it actually writes to the virtual terminal and blocks when a c-list some where fills up. 3) You can't signal a process to tell it to 'repaint' the screen with the V.2 JC stuff. Is there anyway to get around that? 4) The presenter (cant remember who) made the comment that the Berkeley JC had severe problems with its definition. I've never loved the implementation but isn't the problem in the implementation rather than the definition? 5) The comment was made (by the presenter) that his JC stuff is a poor mans BLIT. Why then is it called job control when it is more a primitive window manager (complete with virtual ttys!!)? Oh well, enough questions, I'm sure right now some one is honing up their axe.
guy@rlgvax.UUCP (Guy Harris) (02/01/84)
> (An aside, was I halucinating or were people REALLY booing > the presenter?) No, you were not hallucinating. > Anyway, my questions: > 3) You can't signal a process to tell it to 'repaint' > the screen with the V.2 JC stuff. Is there anyway to get > around that? No. That is one reason people were booing the presenter. > 4) The presenter (cant remember who) made the comment that > the Berkeley JC had severe problems with its definition. > I've never loved the implementation but isn't the problem > in the implementation rather than the definition? I don't remember what the comment was, but it is interesting to note that most UNIX programs (all those which don't put the terminal or the tty channel in a non-standard mode or move the cursor other than by outputting lines) don't have to change *at all* to work with job control. Those that print a prompt *can* be changed (it improves their esthetics), but *need* not be. Screen editors probably don't *have* to be changed, either, but they're a *lot* nicer if they do - if they don't, they give the same inadequate behavior as the S5R2 "job control" does. > 5) The comment was made (by the presenter) that his JC stuff > is a poor mans BLIT. Why then is it called job control when > it is more a primitive window manager (complete with virtual > ttys!!)? It's called "job control" because, to some degree, it's a marketing ploy. It is truly a primitive window manager; you can't "control jobs" by stopping them. It also has no way of notifying the program that it has had control of the terminal taken away from it, which means that any program which assumes that it has total control of some terminal, either physical or virtual, won't work unless the virtual terminal mechanism is modified to track all the changes to the terminal state made by that program and to always switch the state of the physical terminal to match the state of the currently active virtual terminal. This would mean it would have to keep a *FULL* screen image, and keep track of all sorts of internal state for the virtual terminal. This either means it has to know everything about every model of terminal anyone would ever hook up to a system running S5R2, or it has to provide a "virtual terminal" which is a powerful enough model to be sanely emulated on every model of terminal anyone would ever hook up to a system running S5R2. In short, to do it "correctly" would mean implementing a gigantic package which would dwarf "curses" in complexity either inside the kernel or in a process connected to all terminals using the virtual terminal facility with a multiplexed-file like facility; I'm not even sure this is implementable given the variety of terminals out there. So any claims by Bell that this is the "correct" way to do it, as opposed to the Berkeley method which is "incorrect", are bogus. The Berkeley method distributes knowledge about the peculiarities of the terminal to the programs using the terminal; the Bell method tries to centralize this knowledge but fails because the only such knowledge that it centralizes is the "ioctl"-settable tty port modes. Consider the "ged" program - a Graphical EDitor, supplied with S3 and S5, for the Tektronix 4014 - modified to work on a "VT100-plus-graphics-board" terminal which has a VT100 mode and a separate TEK4014 emulation mode. Now try to imagine this running on a "virtual terminal" using the S5R2 virtual terminal facility. Can you say "totally scrambled screen?" I thought you could! The "layer shell" doesn't know doodley about turning the TEK4014 emulation mode on or off. You would have to implement commands in "ged" to turn emulation mode off and clear the screen, and to turn emulation mode back on and redraw the screen. Then, you would have to run the first command before switching out of that layer and run the second command before switching into that layer. But why not just have a signal sent to the program which tells it that its layer is being left or entered? Then the program could automatically run those commands which would make the user interface to the layers facility infinitely superior (less chance for errors, less typing, etc. - "cleaner and simpler but much more of a pain to use" is usually *not* a win). Well, that's what SIGSTOP and SIGCONT are for in the Berkeley job control mechanism. It sounds like they adapted an idea that wins on the Blit (because the Blit is specialized hardware and software *designed* so that a virtual terminal idea will work) and tried to make it work on arbitrary hardware. Given how arbitrary terminals can be, I'm not surprised that such an attempt failed. Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy
tjt@kobold.UUCP (02/02/84)
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 x275usenet@abnjh.UUCP (usenet) (02/02/84)
Personally, I think the most interesting thing about the sys Vr2 "Job Control" feature, is that it is not integrated with the Blit Support (separately priced) feature package. The result is that we now have two incompatible ways of accomplishing what amounts to the same thing. I talked to the presenter after the talk, and it seems that the implementors of the Job Control feature didn't even bother to go talk to the people doing Blit support. They just went off and did their own thing. Within the limitations of the terminal hardware, there is a lot of commonality between the functions needed to support a Blit and the code to provide Job Control. In the case of the Blit, a lot of the code actually resides in the Blit, in the case of the "dumb" terminal using Job Control, the code resides in the kernel, but there is no excuse for the user having to see the difference, as long as s/he sticks to a prescribed subset of functions. What do you-all think? Rick Thomas ihnp4!abnjh!usenet or ihnp4!abnji!rbt
guy@rlgvax.UUCP (Guy Harris) (02/05/84)
> Within the limitations of the terminal hardware, there is a lot of > commonality between the functions needed to support a Blit and the code to > provide Job Control. In the case of the Blit, a lot of the code > actually resides in the Blit, in the case of the "dumb" terminal using > Job Control, the code resides in the kernel, but there is no excuse > for the user having to see the difference, as long as s/he sticks to a > prescribed subset of functions. The main difference between the Blit multi-layer support and the S5R2 "job control" multi-layer support is that the Blit is an intelligent terminal with a lot of local memory and software specifically designed to support multiple overlapping windows. A "virtual terminal" has several sorts of state information; the ioctl modes of the terminal port, the current contents of the virtual screen of that virtual terminal, and the internal state of that terminal. An example of the latter might be the the state of a VT100's line-wrap option (whether an attempt to put a character in column 81 causes the cursor to move to the beginning of the next line or not), of its keypad (whether it transmits numbers or escape sequences), or of its current character set. The S5R2 "job control" mechanism does preserve the ioctl modes, but it does *not* preserve the internal state of the terminal. To do this, all characters output to the terminal would have to pass through a routine which knew *all* the character sequences that affected the terminal's internal state and would have to interpret them; furthermore, it would have to know how to save and restore that state. It would also have to preserve the screen's contents, so that when switching from one virtual terminal to another the screen would be properly painted with the contents of the new virtual terminal's screen. Another way to do this would be to provide a fake terminal type which is designed for multi-windowing, and have the programs write character sequences for this pseudo-terminal which would be interpreted by a program which knew how to simulate those functions on the actual terminal. All this is difficult at best, and impossible at worst (there may be terminals which simply can't support this). The Blit is different, because its software was specifically designed to make all this possible, so it's not fair to assume that what's available transparently to processes talking to a Blit can be made available to processes talking to arbitrary terminals. Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy
guy@rlgvax.UUCP (Guy Harris) (02/05/84)
> 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
ron%brl-vgr@sri-unix.UUCP (02/07/84)
From: Ron Natalie <ron@brl-vgr> Of course, window managers suck if you don't terminals that do windows real well. I frequently get sick of watching things like that on my VT52 clones that the government gives me to work on. -Ron
phipps@fortune.UUCP (Clay Phipps) (02/07/84)
So the name "job control" is used for a minimal window manager
as a "marketing ploy", eh ?
That's really strange, because the words "job control"
immediately bring to mind
//jobname JOB (000649,10,10,200),'your name here',REGION=512K
//stepname EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=A
//SYSUT2 DD UNIT=SYSDA,DSN=FOO.BAR,SPACE=(CYL,(5,2)),VOL=SER=USER02
// DCB=(LRECL=80,RECFM=FB,BLKSIZE=6400),DISP=(NEW,CATLG)
//SYSUT1 DD UNIT=TAPE9,VOL=SER=REL60,LABEL=(,NL),DSN=NEWREL,
// DCB=(LRECL=80,RECFM=FB,BLKSIZE=2400,DEN=3),DISP=(OLD,KEEP)
//
which is particularly distasteful, if not abhorrent, to the UNIX community.
For the uninitiated, all the above does is copy a single file
from a tape reel to disk.
(Please, no flaming JCL corrections; it's been over 4 years since I've
written any JCL, and good riddance !)
-- Clay Phipps
--
{allegra,amd70,cbosgd,dsd,floyd,harpo,hpda,ihnp4,
megatest,nsc,oliveb,sri-unix,twg,varian,VisiA,wdl1}
!fortune!phipps