Rant about job control (Was: A thought about some things in es.)

["Jeremy Fitzhardinge" <jeremy@suede.sw.oz.au>]

On Jul 10,  8:26pm, Krishna Kunchithapadam wrote:
> But why would anyone be _more_ happy that a kernel does not
> provide any support for job-control?  Does not providing job-
> control make the kernel design any cleaner (in a manner visible
> to programmers and/or users)?  Faster?  Or is it something else
> altogether?

Oh, YES, I'd love to completely lose job control.

We do a product for checkpoint/restart of processes and process groups
(Hibernator, now on SGI's Irix 6.2, whahoo).  We can cope with lots of
things:  mmap, threads, pipes, files, restore pids, etc, but there's
just no way of making a restored interactive program work sensibly with
job control after restart.

Well, there's lots of ways, but there's no way of working out which one
to use automatically, since it depends on what your shell is, and what
you're doing.  We ended up having to add a -j option to restart to say
"this is an interactive program and I'm using job control", and that's
just a compromise between working well and forcing the user to know
much more than they wanted to about sessions/process groups/tty
drivers/etc, etc.

Job control is a mess in both conception and implementation.

Even worse is when you compare the subtly different mechanisms around:
BSD, SYSV, POSIX, and random vendor extentions.  And *then* you get the
amalgam systems which want to please everyone, so you get things like
"posix semantics until you use a BSD call, or use BSD libraries, unless
you use...".

And just look at the goo job control introduces:
- new tty drivers
- SIGTSTP, SIGTTIN, SIGTTOU
- new process group semantics
- sessions (or semantically overloaded process groups)
- a mass of new session and process group system calls
- rewrites of all shells and interactive programs wanting to use them

The last one is the killer.  The introduce a whole pile of stuff to get
some facilities of marginal value.  That would have been vaguely
acceptible if it had been transparent to user apps, but no, you need to
change all *those* too.  And its almost impossible to do portably,
because everyone does it differently, or has different bugs in their
"standard" implementations.  It's really hard to think of a worse
way to multiplex terminals.

The implication of all this is that job control is worse than Irix's
horrific threads/memory sharing "model" (which we can mostly cope
with), which is a truly astounding thought.  At least you can mostly
ignore sproc if you're not using it.

> I use job-control all the time, even though I am on a windowing
> system.  Very often, it is much more convenient for me (in terms
> of keystrokes and response time) to suspend an editor, do a
> "make", and jump back to the editor, all in the same window.

Plan 9 window systems typically pop up new windows instantly,
so there's no speed advantage to not doing so.  Something like
"screen" is a reasonable alternative for Unix hosts which
are too burdened with X to do real work.

	J