Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 GARFIELD 20/11/84; site garfield.UUCP
Path: utzoo!utcsri!ubc-vision!garfield!dave
From: dave@garfield.UUCP
Newsgroups: net.unix-wizards
Subject: Re: to job control or not to job control (was UNIX Futures)
Message-ID: <267@garfield.UUCP>
Date: Tue, 15-Apr-86 17:38:04 EST
Article-I.D.: garfield.267
Posted: Tue Apr 15 17:38:04 1986
Date-Received: Wed, 16-Apr-86 06:42:17 EST
References: <1524@wucs.UUCP> <6571@utzoo.UUCP> <1097@psivax.UUCP> <198@desint.UUCP>
Sender: news@garfield.UUCP
Reply-To: dave@garfield.UUCP (David Janes)
Distribution: net
Organization: Semi-Optimal Software Solutions (Inc.)
Lines: 13

In article <198@desint.UUCP> geoff@desint.UUCP (Geoff Kuenning) writes:
| Stopping a job is a scheduling decision, nothing more.

Not at all. It is informing the process that it's enviroment
is going to change - the screen is going to be messed up. Processes
which don't care about the screen state can ignore it, processes
that do can do something about it. Same with SIGWINCH.

dave
-- 
The             UUCP: {utcsri,ihnp4,allegra,mcvax}!garfield!dave
Mercenary     CDNNET: David Janes <dave@garfield.mun.cdn>
Programmer    "There can only be one!"