Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!philabs!cmcl2!harvard!talcott!panda!genrad!decvax!decwrl!pyramid!hplabs!sdcrdcf!trwrb!desint!geoff
From: geoff@desint.UUCP (Geoff Kuenning)
Newsgroups: net.unix-wizards
Subject: Re: to job control or not to job control (was UNIX Futures)
Message-ID: <198@desint.UUCP>
Date: Sat, 12-Apr-86 17:58:32 EST
Article-I.D.: desint.198
Posted: Sat Apr 12 17:58:32 1986
Date-Received: Sun, 20-Apr-86 09:47:08 EST
References: <1524@wucs.UUCP> <6571@utzoo.UUCP> <1097@psivax.UUCP>
Reply-To: geoff@desint.UUCP (Geoff Kuenning)
Organization: SAH Consulting, Manhattan Beach, CA
Lines: 21

In article <1097@psivax.UUCP> friesen@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