Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!weretis.net!feeder1.news.weretis.net!feeder.erje.net!newsfeed.xs4all.nl!newsfeed6.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
Date: Tue, 3 Jan 2012 10:38:03 +0100
From: =?UTF-8?B?SsOpcsO0bWU=?= <jerome@jolimont.fr>
Cc: python-list@python.org
Subject: Re: Avoid race condition with Popen.send_signal
In-Reply-To: <CAPTjJmqnzpLw8qHWkPQmcX=At0-OpPy1up0wBBfp3eLPrhKoFg@mail.gmail.com>
References: <CABicbJKPmckzRwKa9BgTzP8p+nVO98eKh2s1=ZDjBSoY-N1OvQ@mail.gmail.com> <mailman.4327.1325555666.27778.python-list@python.org> <63817f2b-ccf8-4d7d-92a6-c1d622986d8a@j10g2000vbe.googlegroups.com> <20120103094415.072db024@bouzin.lan> <CAPTjJmqnzpLw8qHWkPQmcX=At0-OpPy1up0wBBfp3eLPrhKoFg@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.4342.1325583331.27778.python-list@python.org>
Lines: 94
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: x330-a1.tempe.blueboxinc.net comp.lang.python:18389

Tue, 3 Jan 2012 19:58:57 +1100
Chris Angelico a =C3=A9crit:

> On Tue, Jan 3, 2012 at 7:44 PM, J=C3=A9r=C3=B4me <jerome@jolimont.fr> wro=
te:
> > 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) ?
>=20
> 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.
>=20
> (I can't make a statement on Python's module, though.)

Thanks for clarifying this.

(Out of curiosity, what would be the way to be sure when not in "normal
circumstances" ?)

So I rely on the OS for not allocating a "recently released" PID. However, =
if
the PID was released long ago, I still need to cover myself up as Popen won=
't
do it for me.

E.g.:

I have an application that can spawn a subprocess to play a beep. I want it
to kill the subprocess when exiting.

To do so, my close() method must

  a/ Check if any subprocess has actually been launched (I store the Popen =
in
  a variable called _beep_process. If Popen has not been called, the variab=
le
  is init to 0 and the call to send_signal will fail.)

  b/ Check if the process is still alive using Popen.poll() and returncode
  (otherwise, I might kill a new process)

  c/ Catch the exception in case the process would be dead since the last
  check (otherwise, I might get an error from send_signal)


It looks like this :

    #####################################################################
    # Close
    #####################################################################
    def _close (self, widget):
        # If self._beep_process !=3D 0, a subprocess was launched at some p=
oint
        if (0 !=3D self._beep_process):
            print "process launched"
            self._beep_process.poll()
            # If process still alive
            if (None =3D=3D self._beep_process.returncode):
                print "process stil alive"
            # Send signal
                try:
                    self._beep_process.send_signal(signal.SIGINT)
                except OSError, e:
                    if e.errno =3D=3D errno.ESRCH:
                        print "process just died"
                        pass      # process already dead
                    else:
                        raise     # something else wrong - raise exception
                else:
                    print "signal sent"
                    # wait for process to complete
                    self._beep_process.wait()
            else:
                print "process already dead"
        # Close application
        Gtk.main_quit()
    #####################################################################

I would have expected something shorter.

For instance, Popen.send_signal() should not be able to send a signal to a
subprocess that has already returned, should it ? Is there any good reason
for allowing it to do so ? If not, it would spare me check b/ in this examp=
le.

--=20
J=C3=A9r=C3=B4me