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