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

[John Mackin]

In article <127 at sering.mcvax.UUCP> dpk at sering.UUCP (Doug Kingston) writes:

> I use BLIT terminals and SUN-like
> workstations every day.  However, this does not mean I want to give
> up the ability to STOP and RESTART jobs.  [...]
> In order to get a consistent coredump
> you must insure the process is NOT running.  Job control allows you
> to accomplish just that.  It is then possible to safely collect the
> processes context from /dev/*mem (using the "gcore" program in 4.2BSD).
> You can then continue the process afterwards with no ill effects.
> [...]
> In summary, look at the broader uses of BSD job control before condemning
> its usefulness.  Its not just for allowing simultaneous processing.  [...]
> I believe that the BSD facilities and many more are
> provided through /dev/proc on V8 Unix, although they may not be as efficient.

Well.  First of all let's split some hairs.  [Please note that I'm
not attacking you or your posting, but I do value correctness...
ok, I'm pedantic.]

I do not think you use Blit terminals (note correct capitalization)
every day.  I am quite certain that what you mean is that you
use Teletype DMD5620 terminals every day.  A Blit is a research
terminal, manufactured first at Bell Research and then by Teletype
exclusively for Bell Research.  No Blits have ever been sold commercially.
They have a 68000 cpu and 256K of ram which cannot be expanded.
Blits have a VT-100 style keyboard; the key layout is precisely the 
same as a VT-100.  The Teletype DMD5620 is a commercial product.
It has a WE32000 cpu and 256K of ram which can be expanded to 1M.  
It has a completely different keyboard, with white, low-profile
keys.

I emphasize this because I am typing this on a Blit.  We have
an Eighth Edition license and Bell Research have donated 12
Blits to us.  The Teletype DMD5620 can be unambiguously
referred to as: a 5620 (probably best), a dmd (popular with
SysV'ers) and a dud (but not many people outside the Labs
call them that).  The term "jerq" should be avoided as it can
refer to either a Blit or a dud depending on context
(to a person at the Labs, it means a Blit; to a person at
a non-Labs V8 site, it probably means a dud).

Also on terminology, you refer to /dev/proc.  The conventional
mount point of the Eighth Edition process file system is /proc.
I do not believe anyone ever mounts it on /dev/proc.

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.

You say as much, but then you say you still want to be able to
stop and restart processes.  On V8, that is as easy as opening
the process' /proc entry and doing a single ioctl().  No harder
than doing a kill().  For the purposes you say you use the
facility, having it generated from a character typed on the
controlling terminal (^Z) is pretty pointless.  So there's
no clear advantage there.

I'm not sure what you mean by saying that the V8 ways of
doing things ``may not be as efficient''.  I think it's
pretty clear that the number of milliseconds it takes to
stop a process doesn't matter at all, given the very
low frequency with which it is done; and in any case,
it's not clear that V8 will do this any less efficiently
than other systems.  And if you mean efficient in terms of
efficient for the user -- believe me, V8 is by far the
best UNIX environment I've ever used (I've used quite
a few).  The software you get for 5620's with the SysV
layers package, or with BSD, is nowhere near as nice
as that under V8.  Please don't judge Eighth Edition
on the basis of inferior imitations.

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.

John Mackin, Basser Department of Computer Science,
	     University of Sydney, Sydney, Australia

seismo!munnari!basser.oz!john	john%basser.oz at SEISMO.CSS.GOV