to job control or not to job control (was UNIX Futures)

[Stanley Friesen]

In article <6571 at utzoo.UUCP> henry at utzoo.UUCP (Henry Spencer) writes:
>
>Agreed, it's not unique to BSD; V8 has it too, in a much cleaner form.
>Furthermore, it is a feature that has nothing much to do with the rest
>of job control.  It's easy to envision putting it into a window system --
>just have a way to stop all processes run from a particular window.  Not
>send a signal to them, but simply freeze them instantly.  This does mean
>you need to have another window so you can do something	with them once
>they are frozen, but that's reasonable enough.

	This implementation would violate the spirit of UNIX systems.
No process should be placed in a new state from outside, a signal
*should* be sent, just in case the process needs to do some sort of
clean-up before suspending. Other than insisting on a signal though, I
agree that this aproach is nice. But only if it will work on *any*
terminal, not just bitmapped terminals!
>
>> Job control frees up system resouces by allowing processes to be
>> swapped out.  Window systems leave processes lying
>> around, and clutter the system even more with a window managing process!
>
>There is no obvious reason why a window system can't let processes be
>swapped out when they are stopped.  Of course, it also gives you the freedom
>to let them continue running, if that is what you want.  As for a window
>management process, once again you get what you pay for.

	Of course, in fact the system need not even know how a process
has been stopped, only that it has. Hmm, another reason for a SIGSTP
instead of "instant" stopping, other processes besides the Window
Manager may wish to stop processes(such as a debugger).

> Surely it is
>wasteful to have a shell cluttering up the system while you're using an
>editor, and hence Unix is inferior to a system with the command interpreter
>wired into the kernel.  Right?
>
	I hope this is a :-)! I much prefer a minimal kernel with
other functions in ordinary application programs. What I would like to
see is the basic hooks for window management in the kernel, such as
virtual terminals and a set of signals and primitives for managing
them with a Window Shell doing the actual user interface.

>>   I would be very annoyed if somebody put screen control into
>> the kernel (!) and forces a screen update (expensive at 1200 baud) every time
>> I jumped into and out of a process.
>
>It's a feature when you don't want to bother with the screen update.  It's
>a bug when you want that screen update but can't get it.  Especially when
>the only way to get it is to modify a tremendous pile of programs that
>otherwise wouldn't need that complexity.
>
	What he is saying is that however windowing is implemented it
needs to be able to handle "no-redraw" windows for cases where it
would be unecessarily expensive to redraw the window when it is
reactivated. That is there must be someway of preventing the system
from redrawing a screenfull of trivial messages and old commands at
1200 baud over a phone line just because the window containing them
has been suspended and restarted!

	There has been a lot of flaming on this subject, why don't we
try to shift to a more constructive discussion. What features are
necessary in a windowing system to make it generally useful and
acceptable?
-- 

				Sarima (Stanley Friesen)

UUCP: {ttidca|ihnp4|sdcrdcf|quad1|nrcvax|bellcore|logico}!psivax!friesen
ARPA: ttidca!psivax!friesen at rand-unix.arpa