Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ut-sally!std-unix
From: std-unix@ut-sally.UUCP (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: job control
Message-ID: <6195@ut-sally.UUCP>
Date: Sat, 1-Nov-86 19:13:29 EST
Article-I.D.: ut-sally.6195
Posted: Sat Nov  1 19:13:29 1986
Date-Received: Mon, 3-Nov-86 21:56:29 EST
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Lines: 26
Approved: jsq@sally.utexas.edu

From: seismo!vrdxhq!inteloa!omepd!jimv (Jim Valerio)
Organization: Intel Corp. Hillsboro, Oregon
Date: Wed, 08 Oct 86 14:59:16 -0800

I object to one claim made by Henry Spencer on job suspension:
>Note that this suspension facility isn't very useful in  the  absence  of
>multiplexed  interaction  --  you  can't  *do* anything to a suspended process
>without access to another (real or virtual) terminal -- but the  two  concepts
>are nevertheless quite independent.  There is no need to confuse them.

Completely independent of terminal interfaces, job suspension is a
useful feature.  In particular, I have a batch queue mechanism in
mind on 4.2bsd UNIX which suspends batch jobs when the interactive
load gets too high, and restarts them (sending SIGCONT) when
the interactive load drops again.  This control can be done both
by an operator and by a daemon, and has no notion of controlling
terminal for the batch job.

As Henry indicates, job suspension and multi-process control are
two different items.  Even though job control may not be the only
or best way to implement multi-process control, job suspension is 
an important feature in its own right.
--
Jim Valerio	ogcvax!inteloa!omepd!jimv, tektronix!psu-cs!omepd!jimv

Volume-Number: Volume 8, Number 15