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

Henry Spencer henry at utzoo.UUCP
Tue Apr 8 08:41:22 AEST 1986


>  > > ...What good does it do to stop
>  > > a job if I cannot restart it transparently?
> You can.

If it is prepared to be restarted, i.e. to redraw its screen.  This is not
what is usually referred to as "transparent", since every program has to
know about it.


> Since when does EVERY program have to redraw the screen?  I stop and start
> compiles, makes, news-readers, mail, etc. and none of them do screen refreshes.

And therefore you lose their screen output when you restart them.  This is
a bug, not a feature.  Agreed that sometimes redrawing the output would
incur unneeded overhead when you don't particularly care about the output,
but this is like saying that SVR0 doesn't incur the overhead involved in
providing virtual memory -- yes, it's cheaper, but at the cost of not
providing a valuable and important capability.

> Job control is a helluva lot more than a cheap imitation of a window system.
> It is a general method of allowing some user control of system features -- 
> time sharing and resource sharing.  Remember that ^Z is only a character hook
> to the rather general SIGTSTP signal! 

Name three other uses of SIGTSTP.

> The ability to stop a process is a
> very nice features that is NOT unique to BSD Unix...

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.

> Further, I think window systems are just fine, but they require VERY special
> hardware to give acceptable performance.

I know people who would dispute this.  That aside, though, cheap plastic
imitations are usually cheaper than the real thing.  You get what you pay for.

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

> The fact that a job can catch or not catch the SIGCONT as it pleases is a very
> useful FEATURE!  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.

> Don't clutter this group with off-the-cuff opinions and snorts!  Both job
> control and window systems have their place...

That is itself an off-the-cuff opinion, and one that I snort at. :-)
-- 
				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,decvax,pyramid}!utzoo!henry



More information about the Comp.unix.wizards mailing list