Eighth Edition and job control (was Re: UNIX Futures)

[Guy Harris]

> Now that I've got that out of the way, let's go on to discuss
> so-called job control.  The whole point about Berkeley job control
> is, it is a massive hack.  Witness the huge number of user-mode
> programs that had to be modified to know about SIGTSTP, etc.
> Not to mention the far-reaching kernel modifications.  I think
> we can agree that a window system *in which the user program
> need have no idea that it is running in a window* is much better.

Yes, a number of programs did have to be modified.  Most didn't.  Roughly 7%
were modified.  If you then drop in, say, a bunch of S5 (or V8, or whatever)
programs, most of them need no modification.  The programs that were
modified were modified because:

	1) they need to undo what they've done to the terminal if they get
	   stopped (note that this doesn't just mean "clear the screen")
	   and redo it when they're restarted (note that this doesn't just
	   mean "redraw the screen") - this covers about 7 programs

	2) they need to prevent themselves from being stopped while in
	   a critical region - this covers about 4 programs

	3) they need to be able to report what the signal that stopped
	   a child process was - this covers about 2 programs

	4) they need to set up the initial signal environment for a
	   login session - this covers about 3 programs

	5) they need to be able to control jobs - this covers 1 program

("halt" and "reboot" use it because they have to tell "init" something and
"init" uses SIGTSTP for this; "init" uses it because it's there, not because
it has any real significance.)  Yes, it's a nuisance, but I don't think it
justifies uncritical claims about how awful job control is because of "a
huge number" of programs requiring modification because of it.

Yes, I agree that a window system (which job control is NOT) which permits
programs to run without having to know that they're in a window is better
than one which doesn't.  I rarely use job control here, because I have such
a window system.  However, bit-mapped terminals and workstations are
expensive, and saying that thus-and-such a problem is solved completely and
correctly by such machines is all well and good, but it doesn't mean that
this solves everybody's problem or that no other solutions should be
considered.  (To give another example, it has been argued that terminals
like Blits render the ^R control character and the "printing terminal erase"
mode of 4.2BSD unnecessary.  What they really mean is that such features are
unnecessary *if you have something like a Blit*.  Since not everybody does,
such features are still useful.)

> As far as stopping, making a core, and restarting goes, or in
> general for debugging anything, may I recommend the V8 debugger,
> ``pi''.  I could easily use too many superlatives talking about
> pi.  Let me just say that it is a lot more satisfying to be
> able to dynamically bind the debugger to any process in the
> system, *while it is executing*, and set breakpoints, examine
> its stack, ... than to take a core dump and prod that.  (Of
> course you can simply stop the process, too.)  Think of it
> this way: there's a certain beauty in surgery, but autopsies
> just stink.

Yes, I certainly agree.  I'm not running V8 on my machine, but I can do this
too.  (We don't even have "/proc", but we do have some additions to
"ptrace".  Of course, it would be possible to implement "/proc" here using
the "virtual file system" mechanism that the UNIX file system and the NFS
file system are plugged in to.)

Besides, autopsies may be a pain, but if someone wheels a corpse into your
office and asks you what the cause of death is, you don't have much choice.
-- 
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy at sun.arpa	(yes, really)