Avoid race condition with Popen.send_signal

Adam Skutt askutt at gmail.com
Tue Jan 3 09:20:53 EST 2012

On Jan 3, 3:58 am, Chris Angelico <ros... at gmail.com> wrote:
> On Tue, Jan 3, 2012 at 7:44 PM, Jérôme <jer... at jolimont.fr> wrote:
> > If so, I don't see how I can protect myself from that. Checking the process
> > is alive and then hoping that the time interval for the race condition is so
> > small that there are few chances for that to happen (because the OS
> > quarantines PID numbers for a while, for instance) ?
> The probability is extremely small. PIDs are generally allocated
> sequentially, and obviously one won't be reallocated until the
> previous process has terminated. You're looking at a narrow window of
> opportunity between a check and an action; you don't really need to
> worry about PID reuse within that window, unless there's a particular
> reason to fear it (eg your process is very low priority, or there's a
> lot of "process spinning" happening). Under normal circumstances, you
> won't see a new process start up with the same PID for some time.

Not all operating systems attempt to generate sequential processes
IDs.  The window can be rather large in certain situations, and if you
cannot rely on your child processes becoming zombies and kill being
called only when the child is alive or a zombie, then you should not
be calling kill(2) at all.  Killing an unrelated process will be
considered as a bug by users.  Hence why I find it easier just to
avoid the problem altogether if I can.


More information about the Python-list mailing list