job control, scheduling, and signals
chris at umcp-cs.UUCP
chris at umcp-cs.UUCP
Mon Apr 14 21:02:12 AEST 1986
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
More information about the Comp.unix.wizards
mailing list