richards@uiucdcsb.UUCP (10/10/84)
Re: Windows vs Job control
There are two reasons I wouldn't consider windows to be equivalent to job
control:
1) If you have windows, and not job control, you have not the freedom
to change your mind about forground/background once you have
started. You have committed yourself to using the resources
required by a window (which in most cases is not insignificant
e.g. bitmap memory, additional tty ports, perhaps a server
process or shell for the window, display real estate), even if
you don't intend to interact again with it, or do so only for
an initial dialog. Additional processes don't require the same
resources as opening new windows. (At least in the window
systems I'm familiar with. I'm all for cheaper hardware,
but it isn't *that* cheap yet.)
2) Job control gives you the opportunity to make a running program
"pause", so you can check intermediate results (particularly
helpful if debugging). Many a time I start jobs that work on
big files in the background, then check up on them while they
are in progress. Sometimes the result looks questionable, so
I "stop" the process and do more detailed investigating. I
appreciate the ability not to have to "kill" the job, then
start it again if it really was working correctly. Also, I
can use the job control facilities to decide what background
jobs I want to run concurrently, and modify that decision
after the original instantiation, without losing work already
accomplished.
I believe both have their place, and enjoy using systems that have the
flexibility to provide both.
Paul Richards University of Illinois @ Urbana-Champaign
UUCP: {pur-ee,convex,inhp4}!uiucdcs!richards
CSNET: richards.uiuc@csnet-relayguy@rlgvax.UUCP (Guy Harris) (10/12/84)
> There are two reasons I wouldn't consider windows to be equivalent to job > control: > > 1) If you have windows, and not job control, you have not the freedom > to change your mind about forground/background once you have > started. You have committed yourself to using the resources > required by a window (which in most cases is not insignificant > e.g. bitmap memory, additional tty ports, perhaps a server > process or shell for the window, display real estate)... The tty ports (or pseudo-tty ports), shell, and possibly bitmap memory will still be required by new windows, but I would hope the window package would at least let you cover the "uninteresting" window with another window. (Which doesn't affect the point much, as the critical resource is probably likely to be pseudo-tty ports; f'rinstance, the System V Release 2 "job control" facility has only 8 "layers", which I presume is not too far off from the number of real layers offered by the Blit/5620 software.) > 2) Job control gives you the opportunity to make a running program > "pause", so you can check intermediate results (particularly > helpful if debugging).... That's why it's called "job control", and why I always put references to it in quotes when referring to the System V pseudo-window scheme. The S5 scheme doesn't allow you to control jobs (stop them, restart them, etc.); it's just a window manager without windows and without the benefits thereof. > I believe both have their place, and enjoy using systems that have the > flexibility to provide both. I agree 100%; they solve two different (but not disjoint) sets of problems. Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy