job control, scheduling, and signals

[geoff at desint.UUCP]

Sigh.  Anytime somebody as bright as Chris Torek misunderstands what I
say, I just *know* I could have said it better.  Let me try again.

In article <897 at umcp-cs.UUCP> chris at maryland.UUCP (Chris Torek) writes:

> 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:

There is a difference between having a process participate in its scheduling
decisions by notifying the scheduler of its needs, and in having a
process notified of entirely arbitrary scheduling decisions made by
an outside force.  The time range is relevant only to efficiency
(though I will note that I have seen jobs swapped out for minutes at
a time on heavily-loaded systems).

> >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.

Sorry, but what I meant was this:  the decision to "stop a job", in the
context I was discussing, means "prevent this job from proceeding further".
That decision may be INITIATED by a user, but it's still a scheduling
decision in the sense that the SCHEDULER is not going to grant any more
CPU cycles to that process until the decision is changed.  Furthermore,
this statement was made in the context of a discussion that explicitly
separates the decision to "prevent this job from proceeding" from the
decision to "return the interactive user to the command interpreter
or to a different previously-active process".  Indeed, these are two
different functionalities, and there is no reason to lump them together
as in BSD just because "stopping a job" (as a scheduling decision) is
a necessary prerequisite to "returning the user to the command
interpreter".

Stopping a job from access to a system resource is a scheduling decision,
no matter who initiates it.  It is useful in numerous situations;  one
of them is implementing "cheap windows".  In that situation, and in
that situation *alone*, it is useful to notify the suspended process of
the scheduling decision so that it can un-do whatever damage it has done
to the terminal/stty settings.

In all other situations, there is no reason for a suspended job to
know about scheduling decisions.  Furthermore, it would have been quite
easy to develop a simple handshaking protocol for handling the notification;
csh (in BSD) or shl (in Sys V) knows that the user has just "switched away"
from a process (else how would it know to put out a prompt)?  It is not
really very hard to design a protocol with the desired characteristics
(e.g., it's reliable, yet it can be ignored by most programmers).

> 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...

Nobody denies that need;  I just pointed out that BSD lumped the
implementation together with a piece of the scheduler in an extremely
inelegant fashion.  There is nothing to prevent 'shl' from executing
some convention that would notify subject programs to restore screens
automatically.

Personally, I just look at it this way:  in BSD, to restart vi, I have
to type "%vi^M" (where ^M is my CR).  In SysV, I type "vi^M^L".  It's
even the same number of keystrokes :-).

> 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.

A complete implementation of this suggestion is not practical except
on bitmap terminals (which usually have windowing already).

> (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.)

While I don't deny the pain of working at low baud rates (I had to dust
off my 300 modem the other day), I would hate to add another feature
to a system to handle a problem as obviously transient as this one.  In
the second place, baud rates are going up like a rocket, but in the first
place the trend is toward intelligence at the local end of the phone line
so the context repaint doesn't require lots of data.  If we decide to
solve this one, let's make sure it's a temporary solution that we don't
have to live with forever.
-- 

	Geoff Kuenning
	{hplabs,ihnp4}!trwrb!desint!geoff