Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!seismo!ut-sally!std-unix
From: std-unix@ut-sally.UUCP (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: mod.std.unix P1003 job control proposal
Message-ID: <6102@ut-sally.UUCP>
Date: Sat, 25-Oct-86 22:26:26 EST
Article-I.D.: ut-sally.6102
Posted: Sat Oct 25 22:26:26 1986
Date-Received: Sun, 26-Oct-86 04:37:52 EST
References: <5993@ut-sally.UUCP>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Lines: 69
Approved: jsq@sally.utexas.edu

From: seismo!munnari!yabbie.rmit.oz!rcodi@sally.utexas.edu (Ian Donaldson)
Date: Tue, 21 Oct 86 10:39:40 EST

> From: im4u!caip!hplabs!hpda!hpisoa1!davel@sally.utexas.edu (Dave Lennert)
> Date: Thu, 9 Oct 86 14:06:30 pdt
 
>        saved process group ID
> 	     An	active process has a saved process group ID that is
> 	     set to the	saved process group ID of the parent
> 	     process at	the time of creation of	the process (via
> 	     the fork()	function).  It is reset	to the process
> 	     group ID of the process when the process successfully
> 	     calls one of the exec functions.

What is the significance of the "saved process group ID"?  How is
it different to the normal process-group-ID?  Who uses it?
 
>        In section 3.2.2.2 Description of the _exit function replace
>        the paragraph:
 
>        with:
> 
> 	     If	the process is a session process group leader, the
> 	     SIGHUP signal may be sent to each process that has	a
			   ^^^ should be replaced by the word "will"
> 	     process group ID equal to that of the calling process;
> 	     also, all such processes may have their process group
> 	     ID	set to zero.
> 
> 	     If	the implementation supports the	job control option
> 	     and if the	calling	process	has child processes that
> 	     are stopped, they will be sent SIGHUP and SIGCONT
> 	     signals.
> 

I disagree with the proposal on the handling of _exit processing for
job control.  It should be possible to not have to know in advance
that you wish to log-off and leave something running that you started
in foreground and later shifted to background.  This is a KEY feature
of job control.  

vhangup() will provide clean terminals on a bsd system,
and we have improved vhangup further to not just turn off READ/WRITE bits,
but to actually redirect the file references to /dev/null (which has
the advantage of also dropping DTR reliably). 
Infinite-loop processes don't cause problems with system-response because
they are automatically niced (something that is long-needed in UNIX systems).

I see no mention of a vhangup equivalent in this proposal segment, but
then again, I haven't seen the whole of P1003 either.

I find the SIGHUP being sent by exiting processes to sub-proceses
a plain nuisance, and it does nothing for productivity.  Nohup(1)
is effectively obsoleted by job control, since the process won't
receive signals from terminals when they are in background anyway.

One if the KEY things about job-control is that you don't have
to "know in advance" what you plan to do.  Nohup(1) requires that 
you do known in advance, and with the above proposal, nohup(1) IS
required if you want to leave jobs running when you log-off.

The SIGHUP and SIGCONT signals are only sent to processes in the
terminal process group when modem carrier disappears on a BSD system.
Children of init that are stopped are also sent SIGHUP's and SIGCONT's.
Children of init that aren't stopped aren't sent anything.

Ian Donaldson

Volume-Number: Volume 7, Number 84