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

[Jack Jansen]

In article <198 at desint.UUCP> geoff at desint.UUCP (Geoff Kuenning) writes:
>
>Taking this at face value, given the current scheduler states in the UNIX
>kernel, we need SIGSWAP, SIGBLOCK, and SIGRUN at an absolute minimum.
>
>Sorry, Stanley, but Henry's right and you're wrong.  A process should not
>be informed of scheduling decisions;  it's contrary to the very spirit
>of multiprocessing.  Stopping a job is a scheduling decision, nothing more.
>(O.K., I admit BSD has hung a bunch of other stuff on it.  But that's their
>problem).


Sorry, Geoff, but I agree with Stanley. There's a *very* big difference
between scheduling and stopping jobs: stopping is done by the
user.

Another difference is on the time-scale. Usually, a job isn't swapped
out for too long (except on boring:-), while a stopped job can
remain stopped for a long while.
I can imagine programs that hold critical locks would like to give
them up when they find out they're about to be stopped.
-- 
	Jack Jansen, jack at mcvax.UUCP
	The shell is my oyster.