Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxn!ihnp4!houxm!whuxl!whuxlm!akgua!gatech!seismo!umcp-cs!chris
From: chris@umcp-cs.UUCP
Newsgroups: net.unix-wizards
Subject: Re: job control, scheduling, and signals
Message-ID: <897@umcp-cs.UUCP>
Date: Mon, 14-Apr-86 06:02:12 EST
Article-I.D.: umcp-cs.897
Posted: Mon Apr 14 06:02:12 1986
Date-Received: Thu, 17-Apr-86 04:19:29 EST
References: <1524@wucs.UUCP> <6571@utzoo.UUCP> <1097@psivax.UUCP> <198@desint.UUCP>
Reply-To: chris@maryland.UUCP (Chris Torek)
Organization: University of Maryland, Dept. of Computer Sci.
Lines: 47

In article <198@desint.UUCP> geoff@desint.UUCP (Geoff Kuenning) writes:
>Taking [article <1097@psivax.UUCP>] at face value, given the current
>scheduler states in the UNIX kernel, we need SIGSWAP, SIGBLOCK, and
>SIGRUN at an absolute minimum.  [...] A process should not be informed
>of scheduling decisions;

I am not certain I agree.  Certainly swaps occur, and block/run
states change, too quickly to bother informing the process itself,
but it might well be more `elegant' to let processes do their own
long-term scheduling, instead of enforcing that in the kernel.
But to the matter at hand:

>Stopping a job is a scheduling decision, nothing more.

No!  Not in the way that `job control' means.  Stopping a job is
a *user* decision.

Since control returns to whatever supervisor process is watching
the terminal (usually the C shell), and terminals have states,
there must be some way to save and restore the state.  The 4BSD
approach is to have each program save and restore that state;
and this succeeds fairly well, at the cost of modifying programs:
editors which change terminal input modes and use full screens;
games which use full screens; programs that activate attached
printers and plotters; and so forth.

Perhaps a better method---apparently that taken by `shl'---would
be to have a user level program that would direct input, filter
output (escape sequences can change terminal modes), and handle
state change requests (stty et al.).  Shl, however, does not do a
complete job of this; if it did, a restarted editor would have its
screen back.  But the job is not simple:  A restarted Tektronix
plot running on an H19 with an external graphics board must get
*its* screen back, too, no matter what has intervened.  This user
level program would have to be extremely clever---or there could
be more than one.

(It also seems to me desirable to allow processes to be marked as
noncontextual.  It is hardly worth restoring the full context of
a `bc' session, especially at 1200 baud.)

(Does this sound like a window system?  It is very similar, but
it is not the same.)
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1415)
UUCP:	seismo!umcp-cs!chris
CSNet:	chris@umcp-cs		ARPA:	chris@mimsy.umd.edu