job control, scheduling, and signals

[chris at umcp-cs.UUCP]

In article <198 at desint.UUCP> geoff at desint.UUCP (Geoff Kuenning) writes:
>Taking [article <1097 at 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 at umcp-cs		ARPA:	chris at mimsy.umd.edu