Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!seismo!mcvax!ukc!its63b!xsimon
From: xsimon@its63b.UUCP
Newsgroups: comp.unix.wizards
Subject: Re: System V job control idea
Message-ID: <467@its63b.ed.ac.uk>
Date: Sat, 6-Jun-87 09:02:52 EDT
Article-I.D.: its63b.467
Posted: Sat Jun  6 09:02:52 1987
Date-Received: Sun, 7-Jun-87 09:47:10 EDT
References: <337@tdi2.UUCP> <757@mcgill-vision.UUCP> <165@elan.UUCP> <1662@munnari.oz> <2245@hoptoad.uucp>
Reply-To: simon@its63b.ed.ac.uk (Simon Brown)
Organization: Computer Science Department, Edinburgh University
Lines: 21

In article <1662@munnari.oz>, kre@munnari.oz (Robert Elz) writes:
> If you have job control, a suitably authorised user (ie: root)
> can pick a random process and stop it, to be continued later.

Well, surely the phrase "job control" implies an ability to ``control'' jobs -
not just a simple stop/resume ability. In particular, any system call that
at present can affect only the current process should, in a "full" job-control
environment, be able to control any named process or job. (I guess "process
group" is the closest thing to the concept of "job" that there is at the
moment). - For a suitably authorized controlling process, that is, of course.
For example, things like setuid(), signal(), open(), dup(), close(), etc...
would all have to have job-control variants to "induce" the system-call in
the named process or job. 
Of course, the complexity of implementing such a scheme would be incredible!
-- 
----------------------------------
| Simon Brown 		         | UUCP:  seismo!mcvax!ukc!{its63b,cstvax}!simon
| Department of Computer Science | JANET: simon@uk.ac.ed.{its63b,cstvax}
| University of Edinburgh,       | ARPA:  simon%{its63b,cstvax}.ed.ac.uk ...
| Scotland, UK.			 |				@cs.ucl.ac.uk
----------------------------------	 "Life's like that, you know"