|
Home > Archive > Unix Programming > August 2006 > waitpid() on process group
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
waitpid() on process group
|
|
|
| Is calling waitpid() on a process group the best way to determine if a
child process and all of its descendants (including descendants that
have backgrounded themselves) have been terminated? The problem I have, is
I am building a batching (queue) system, and must be able to track
termination (in way that will portably work on aix, hpux, irix, linux,
solaris, and tru64) of all processes that I create, and their descendants
/ backgrounded descendants. What happens to the PGID of the child
processes if the group leader dies? Will the PGID of the child processes
revert to their own PID? Do I need to create a stub process to make sure
this won't happen?
Is is safe to waitpid() on other processes in the
process group? Might I reap a process that one of my programs descendants
is waiting on?
Any answers to the above, or better suggestions appreciated.
| |
| Barry Margolin 2006-08-13, 7:29 pm |
| In article <pan.2006.08.13.07.10.23.840928@127.0.0.1>,
root <root@127.0.0.1> wrote:
> Is calling waitpid() on a process group the best way to determine if a
> child process and all of its descendants (including descendants that
> have backgrounded themselves) have been terminated?
No. It will return when ANY child in the specified process group
terminates.
> The problem I have, is
> I am building a batching (queue) system, and must be able to track
> termination (in way that will portably work on aix, hpux, irix, linux,
> solaris, and tru64) of all processes that I create, and their descendants
> / backgrounded descendants. What happens to the PGID of the child
> processes if the group leader dies? Will the PGID of the child processes
> revert to their own PID? Do I need to create a stub process to make sure
> this won't happen?
The PGID doesn't change when the group leader dies. The group leader's
PID is used when creating the process group, but I don't think the group
is dependent on the leader from then on.
barmar $ (sleep 100& sleep 100& sleep 100) &
[1] 10567
barmar $ ps -j
USER PID PPID PGID SESS JOBC STAT TT TIME COMMAND
barmar 260 258 260 17a99e0 0 Ss p1 0:00.30 /bin/bash
--noediting
barmar 10567 260 10567 17a99e0 1 S p1 0:00.01 /bin/bash
--noediting
barmar 10568 10567 10567 17a99e0 1 S p1 0:00.01 sleep 100
barmar 10569 10567 10567 17a99e0 1 S p1 0:00.01 sleep 100
barmar 10570 10567 10567 17a99e0 1 S p1 0:00.01 sleep 100
barmar 10307 10306 10307 17a9af4 1 S+ p2 0:00.07 -bash
barmar $ kill 10567
barmar $ [1]+ Terminated ( sleep 100 & sleep 100 & sleep
100 )
barmar $ ps -j
USER PID PPID PGID SESS JOBC STAT TT TIME COMMAND
barmar 260 258 260 17a99e0 0 Ss p1 0:00.31 /bin/bash
--noediting
barmar 10568 1 10567 17a99e0 0 S p1 0:00.01 sleep 100
barmar 10569 1 10567 17a99e0 0 S p1 0:00.01 sleep 100
barmar 10570 1 10567 17a99e0 0 S p1 0:00.01 sleep 100
barmar 10307 10306 10307 17a9af4 1 S+ p2 0:00.07 -bash
> Is is safe to waitpid() on other processes in the
> process group? Might I reap a process that one of my programs descendants
> is waiting on?
It's not possible to wait for or reap any processes other than your own
children. Even when using a negative PID, it will only wait for members
of that process group that are also your children.
> Any answers to the above, or better suggestions appreciated.
I'm not sure there's a fully reliable way to do what you want. What if
one of the descendants starts a new process group of its own?
--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
| |
| William Ahern 2006-08-14, 1:21 pm |
| On Sun, 13 Aug 2006 09:05:59 +0000, root wrote:
> Is calling waitpid() on a process group the best way to determine if a
> child process and all of its descendants (including descendants that have
> backgrounded themselves) have been terminated? The problem I have, is I am
> building a batching (queue) system, and must be able to track termination
> (in way that will portably work on aix, hpux, irix, linux, solaris, and
> tru64) of all processes that I create, and their descendants /
> backgrounded descendants. What happens to the PGID of the child processes
> if the group leader dies? Will the PGID of the child processes revert to
> their own PID? Do I need to create a stub process to make sure this won't
> happen?
> Is is safe to waitpid() on other processes in the process group? Might I
> reap a process that one of my programs descendants is waiting on?
> Any answers to the above, or better suggestions appreciated.
I don't think waitpid() will do what you want. The best idea I could think
of is using a pipe (or many pipes), between the top-level batch process
and it's immediate children. The top-level process must close the write
descriptor, and optionally it's children can close the read
descriptor. All children of _its_ children will inherit the write
descriptor.
You can poll on the read descriptor from the top-level process. Assuming
no process ever tries to write to the pipe, when the pipe becomes readable
then all children (from that descriptor pair) have died; the readiness
notification is for EOF.
To get this right you'll need a unique pair between every immediate
child process and the top-level process. You might be able to get away w/
doing this just once, by having a single intermediate process fork all
other children.
You might also want to dup2() the write descriptors to something really
high, like FILENO_MAX - 1 or use getrlimit(). But... strictly speaking
that shouldn't be necessary, though it would be prudent to make sure the
write descriptor is above 3 (stderr).
|
|
|
|
|