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

[Guy Harris]

> > No process should be placed in a new state from outside, a signal
> > *should* be sent, just in case the process needs to do some sort of
> > clean-up before suspending.
>
> 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.

The statement "no process should be placed in a new state from outside" is,
indeed, ridiculous.  However, stopping a job in the BSD job control sense is
not a "scheduling decision", any more than terminating it with SIGTERM is.
Would you claim that terminating a job is a "scheduling decision" and
therefore the process should not be informed that somebody wants it to go
away?  If you do, I have a job for you cleaning files out of /tmp and
/usr/tmp on the machines here....

Besides, you both have it backwards.  BSD job control doesn't send a signal
to a process because it is being stopped; it stops a process because it
received a signal for which the current action is to stop.  If you type your
stop character at a process which is catching SIGTSTP, your process gets
delivered that signal and jumps off into the SIGTSTP handler.  That's all.
This handler can clean up (just as the SIGTERM handler does) and then stop
itself by resetting the handler for SIGTSTP and sending itself a SIGTSTP
(just as the SIGTERM handler exits after cleaning up - if it wanted to, it
could terminate itself by sending itself a SIGTERM instead).
-- 
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy at sun.arpa