Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!panda!talcott!harvard!seismo!mcvax!boring!jack
From: jack@boring.uucp (Jack Jansen)
Newsgroups: net.unix-wizards
Subject: Re: to job control or not to job control (was UNIX Futures)
Message-ID: <6876@boring.UUCP>
Date: Wed, 16-Apr-86 19:10:32 EST
Article-I.D.: boring.6876
Posted: Wed Apr 16 19:10:32 1986
Date-Received: Fri, 18-Apr-86 08:51:41 EST
References: <1524@wucs.UUCP> <6571@utzoo.UUCP> <1097@psivax.UUCP> <198@desint.UUCP>
Reply-To: jack@mcvax.UUCP (Jack Jansen)
Organization: AMOEBA project, CWI, Amsterdam
Lines: 24
Apparently-To: rnews@mcvax

In article <198@desint.UUCP> geoff@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@mcvax.UUCP
	The shell is my oyster.