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 (Guest Moderator, John B. Chambers)
Newsgroups: mod.std.unix
Subject: Re: mod.std.unix P1003 job control proposal (now vhangup, auto-nice)
Message-ID: <6370@ut-sally.UUCP>
Date: Mon, 17-Nov-86 13:51:48 EST
Article-I.D.: ut-sally.6370
Posted: Mon Nov 17 13:51:48 1986
Date-Received: Mon, 17-Nov-86 21:18:47 EST
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Lines: 42
Approved: jbc@sally.utexas.edu

References:


>From nsc!hplabs!hpda!hpisoa1!davel@pyramid.UUCP Fri Nov 14 22:04:25 1986
Date: Fri, 14 Nov 86 14:40:04 -0800

> From: ihnp4!iwtpu!katzung (Brian Katzung)
> Date: Sat, 8 Nov 86 14:59:33 CST
> 
>      The wait3 system call has provisions for informing the parent when a
> child is suspended, but not when it resumes.  Thus, if an agent other than
> the parent resumes the child, the parent doesn't know about it.  This is
> rare, but not unimaginable.  I've had applications that could have been
> enhanced if the mechanism were "balanced".

You'd also want to sent SIGCLD under these circumstances, to be complete.

We actually breadboarded exactly this internally at HP.  We decided not
to include it in our product or in our POSIX proposal.  This is because
we wanted to provide an interface that is capable of supporting a 4.2
compatible interface on top of it.  This would require a way to turn off
these enhancements.  E.g., the proposal already contains the following:

	- send SIGCLD on child death		[Sys V compatible]
	- send SIGCLD on child death or stop	[4.2 compatible]

We didn't want to add:

	- send SIGCLD on child death or stop or continue

Similarly for wait3() [now known as wait2()].

I'm not saying this additional functionality isn't useful.  I just feel
that it is not so useful that I wanted to further complicate the
interface for it.

Also note that we wanted to provide an interface that could be easily
implemented on top of existing 4.2.

Anyway, that was our reasoning.

-Dave Lennert   HP   ihnp4!hplabs!hpda!davel


Volume-Number: Volume 8, Number 56