Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!cuae2!ihnp4!houxm!genesis!hotlg!nz
From: nz@hotlg.UUCP
Newsgroups: comp.unix.questions
Subject: Re: BSD & Sys5 Job Control
Message-ID: <19@hotlg.ATT>
Date: Mon, 2-Feb-87 14:35:59 EST
Article-I.D.: hotlg.19
Posted: Mon Feb  2 14:35:59 1987
Date-Received: Tue, 3-Feb-87 21:24:18 EST
References: <1324@cadovax.UUCP> <161@piaget.UUCP> <114@dolphy.UUCP> <3702@teddy.UUCP>
Reply-To: nz@hotlg.UUCP (Neal Ziring)
Organization: AT&T-BL Dept. 54315
Lines: 53

In article <3702@teddy.UUCP> jpn@teddy.UUCP (John P. Nelson) writes:
 > In article <114@dolphy.UUCP> jmg@dolphy.UUCP (Jeffrey Greenberg) writes:
 > >In BSD, processes must be coded to properly handle job control. In sys5,
 > >whoever manipulates the terminal driver, is in control.
 > 
 > Wait just a second!!!  "simple" BSD tasks do NOT need to be recoded to
 > be manipulated with job control (i.e they can be stopped and started just
 > fine, thank you), but tasks have the CAPABILITY to catch signals which
 > indicate a job state change.  

True, but not the whole truth.  A process has the option of 
catching the signal (SIGCONT) that
re-starts it, and thus be notified of a change of state from BLOCKED
to READY (remember your OS classes?).  Since there are two stop signals
(SIGTSTP and SIGSTOP) you get flexibility on READY|RUNNING to BLOCKED
state change, SIGTSTP can be caught (and the state change defered or even
defeated), SIGSTOP can not be caught or ignored and in most cases the R|R
to BLOCKED state change is guaranteed to occur.

 >
 > Shl has two major flaws, in my opinion:
 > 
 >     1.  You must set it up in advance 
 > 
 >     2.  Tasks have no notification of state changes. 

Both of these are flaws, but the main problem is the whole philosophy
behind shl.  It is simply NOT a general facility.  While it may be
nice for users some of the time, it is not good enough to let you manage
multiple stacks of BLOCKED processes, and it is no help to the programmer.

 > 
 > Both shl and "job control" are unnecessary if you have a true windowing
 > system.  Both are HACKS to provide capabilities close to window systems
 > using dumb terminals.

Wrong.  For a user, a windowing system does just about everything he could
want, but it still exhibits the same philosophy as shl: the only reason
to control a process is so a user can run multiple processes.  I think it
is best to have BOTH job control (a general process-control facility) and
window management (a general user-interface facility).  Job control could
be very helpful for the window manager designer/programmer.  A programmer
writing a package that uses multiple concurrent processes (none of which
talk to a terminal, so much for the tty driver control approach) can make
good use of the ability to asynchronously start and stop processes.
Other advantages acrue, but you would have to have used a BSD system for
a while to really get into them.

-- 
...nz  (Neal Ziring  @  ATT-BL Holmdel, x2354, 3H-437)
	"You can fit an infinite number of wires into this junction box,
	but we usually don't go that far in practice."
					London Electric Co. Worker, 1880s