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 Return-Path: X-Original-To: python-list@python.org Delivered-To: python-list@mail.python.org X-Spam-Status: OK 0.113 X-Spam-Level: * X-Spam-Evidence: '*H*': 0.77; '*S*': 0.00; 'received:209.85.210.174': 0.13; 'received:mail-iy0-f174.google.com': 0.13; '(eg': 0.16; 'from:addr:rosuav': 0.16; 'from:name:chris angelico': 0.16; 'instance)': 0.16; 'narrow': 0.16; 'terminated.': 0.16; 'wrote:': 0.18; 'jan': 0.19; 'header:In-Reply-To:1': 0.22; 'statement': 0.23; 'module,': 0.23; "python's": 0.24; 'obviously': 0.25; 'message-id:@mail.gmail.com': 0.28; 'allocated': 0.29; 'pm,': 0.29; 'generally': 0.30; 'tue,': 0.32; "can't": 0.32; "won't": 0.33; 'there': 0.33; 'to:addr:python-list': 0.34; 'checking': 0.34; 'window': 0.35; 'unless': 0.35; 'subject:with': 0.36; 'received:google.com': 0.37; "there's": 0.37; 'some': 0.38; 'hoping': 0.38; 'received:209.85': 0.38; 'received:209': 0.40; 'to:addr:python.org': 0.40; 'extremely': 0.40; 'within': 0.60; 'your': 0.61; 'happen': 0.61; '2012': 0.67; 'alive': 0.67; 'probability': 0.67; 'low': 0.74; 'race': 0.77; 'protect': 0.78; 'priority,': 0.84; 'window,': 0.84 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=Sh2eVNrU50OcjSsUlwtbka6mYYx2ogejUflUngsxvZ4=; b=A/9j/gTOUrUA6rkutxXpO/53l1Lsdn7Ha/+zMpjuOHX99dWeqMvH7fIgkK0khAx57d yr8tEaj1nQfkB63w+UX1E9uTPCtvYZ/Bm55dE9Uk6hdEO0bWpNFoQ+ql8zEfzplsRSJM KFRnoHS/a1j48ifqXb737Mc4u2EfEHtm5LuaY= MIME-Version: 1.0 In-Reply-To: <20120103094415.072db024@bouzin.lan> References: <63817f2b-ccf8-4d7d-92a6-c1d622986d8a@j10g2000vbe.googlegroups.com> <20120103094415.072db024@bouzin.lan> Date: Tue, 3 Jan 2012 19:58:57 +1100 Subject: Re: Avoid race condition with Popen.send_signal From: Chris Angelico To: python-list@python.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: python-list@python.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion list for the Python programming language List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Newsgroups: comp.lang.python Message-ID: Lines: 20 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1325581146 news.xs4all.nl 6950 [2001:888:2000:d::a6]:54573 X-Complaints-To: abuse@xs4all.nl Xref: x330-a1.tempe.blueboxinc.net comp.lang.python:18388 On Tue, Jan 3, 2012 at 7:44 PM, J=E9r=F4me wrote: > If so, I don't see how I can protect myself from that. Checking the proce= ss > 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. (I can't make a statement on Python's module, though.) ChrisA