os.wait() losing child?

Nick Craig-Wood nick at craig-wood.com
Thu Jul 12 20:30:04 CEST 2007

Hrvoje Niksic <hniksic at xemacs.org> wrote:
>  Nick Craig-Wood <nick at craig-wood.com> writes:
> >>  I think your polling way works; it seems there no other way around this 
> >>  problem other than polling or extending Popen class.
> >
> > I think polling is probably the right way of doing it...
>  It requires the program to wake up every 0.1s to poll for freshly
>  exited subprocesses.  That doesn't consume excess CPU cycles, but it
>  does prevent the kernel from swapping it out when there is nothing to
>  do.  Sleeping in os.wait allows the operating system to know exactly
>  what the process is waiting for, and to move it out of the way until
>  those conditions are met.  (Pedants would also notice that polling
>  introduces on average 0.1/2 seconds delay between the subprocess dying
>  and the parent reaping it.)


You could get rid of this by sleeping until a SIGCHLD arrived maybe.

>  In general, a program that waits for something should do so in a
>  single call to the OS.  OP's usage of os.wait was exactly correct.

Disagree for the reason below.

> > Internally subprocess uses os.waitpid(pid) just waiting for its own
> > specific pids.  IMHO this is the right way of doing it other than
> > os.wait() which waits for any pids.  os.wait() can reap children
> > that you weren't expecting (say some library uses os.system())...
>  system calls waitpid immediately after the fork.

os.system probably wasn't the best example, but you take my point I

>  This can still be a problem for applications that call wait in a
>  dedicated thread, but the program can always ignore the processes
>  it doesn't know anything about.

Ignoring them isn't good enough because it means that the bit of code
which was waiting for that process to die with os.getpid() will never
get called, causing a deadlock in that bit of code.

What is really required is a select() like interface to wait which
takes more than one pid.  I don't think there is such a thing though,
so polling is your next best option.

Nick Craig-Wood <nick at craig-wood.com> -- http://www.craig-wood.com/nick

More information about the Python-list mailing list