Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!munnari!vuwcomp!duncan
From: duncan@comp.vuw.ac.nz (Duncan McEwan)
Newsgroups: comp.unix.wizards
Subject: Re: Setting process groups
Message-ID: <13102@comp.vuw.ac.nz>
Date: Tue, 1-Dec-87 22:39:08 EST
Article-I.D.: comp.13102
Posted: Tue Dec  1 22:39:08 1987
Date-Received: Sat, 5-Dec-87 12:43:31 EST
References: <1765@unc.cs.unc.edu> <910@mcgill-vision.UUCP>
Reply-To: duncan@comp.vuw.ac.nz (Duncan McEwan)
Organization: Comp Sci, Victoria Univ, Wellington, New Zealand
Lines: 41

In article <910@mcgill-vision.UUCP> mouse@mcgill-vision.UUCP (der Mouse) writes:
>In article <1765@unc.cs.unc.edu>, southard@unc.cs.unc.edu writes:
>> How can I determine what process group id's are not in use?
>
>The only way, as far as I know, to determine what process groups are in
>use is a ps-like program which scans the process table.
>

Although the man page doesn't say so, killpg(2) behaves like kill(2)
when given signal 0 as its second argument.  That is, it checks if you
would be able to send a signal to the given process group.  So if you
get the error ESRCH back from a "killgp(pgrp, 0)" you know that there
are no processes in that process group.  Not that this info is
particularly useful here - Der Mouse's suggestion of adhering to the
convention of using the process group leader's pid is more sensible
than something like

	for (i = 1; i <= 32767; i++)
		if (killpg (i, 0) < 0 && errno == ESRCH)
			break
	...

BTW, while I was playing around with this, I noticed that the man page
for setpgrp(2) does not say it is an error to put yourself in an existing
process group.  A quick look at the 4.3bsd code shows it isn't (it makes
no checks regarding the process group).  Not that this causes any harm
anyway - if you try to killpg a process group containing processes that
don't belong to you, only your own get killed (unless you happen to
be superuser - something to be said for being careful with programs that
run with uid 0 and use killpg).

One other thing I noticed was that on our pyramid running OSx 4.0,
killpg returns no error if it could kill any of the processes in the
process group.  On a VAX running 4.3bsd it returns EPERM if there are
any that it couldn't kill.  Is OSx's behaviour a hangover from it's
4.2 origins, or is it a Pyramid `enhancement' to the way 4.3 works.
The Pyramid behaviour seems more useful to me.

Duncan

Domain: duncan@comp.vuw.ac.nz		Path: ...!uunet!vuwcomp!duncan