to job control or not to job control (was UNIX Futures)

[Stanley Friesen]

In article <198 at desint.UUCP> geoff at 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).

	And SIGKILL, SIGINT and SIGTERM should also be eliminated
because after all terminating a process is "just" a scheduling
decision :-) In fact I see a major difference between low-level
scheduling operations like swapping and blocking for I/O and higher
level scheduling like stopping and terminating jobs. The former are,
or should be totally invisible to the user, the latter are often under
direct user control, and are invariably plainly visible to the user.
I would not want the OS arbitrarily deciding to stop my jobs! And if I
have stopped a job I certainly don't want the OS to restsart it on it
own! The UNIX philosophy is that the high-level, user-oriented
"scheduling" operations are implemented as signals. Whether the signal
is catchable or not is a policy decision. personally I feel all
un-catchable signals should have a catchable equivalent which is the
"usual" or default signal. This allows forced stopping when needed,
but allows flexibility where that is desirable.
-- 

				Sarima (Stanley Friesen)

UUCP: {ttidca|ihnp4|sdcrdcf|quad1|nrcvax|bellcore|logico}!psivax!friesen
ARPA: ttidca!psivax!friesen at rand-unix.arpa