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

[Geoff Kuenning]

In article <1097 at psivax.UUCP> friesen at psivax.UUCP (Stanley Friesen) writes:
> 
> 	This implementation would violate the spirit of UNIX systems.
> No process should be placed in a new state from outside, a signal
> *should* be sent, just in case the process needs to do some sort of
> clean-up before suspending. Other than insisting on a signal though, I
> agree that this aproach is nice. But only if it will work on *any*
> terminal, not just bitmapped terminals!

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

	Geoff Kuenning
	{hplabs,ihnp4}!trwrb!desint!geoff