Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!weretis.net!feeder1.news.weretis.net!feeder.erje.net!newsfeed.xs4all.nl!newsfeed5.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
Return-Path: <modelnine@modelnine.org>
X-Original-To: python-list@python.org
Delivered-To: python-list@mail.python.org
X-Spam-Status: OK 0.055
X-Spam-Evidence: '*H*': 0.89; '*S*': 0.00; 'alter': 0.09; 'am,': 0.12; 'case.': 0.15; 'adam': 0.16; 'received:10.2': 0.16; 'terminated.': 0.16; 'wrote:': 0.18; 'errors,': 0.18; 'jan': 0.19; '(which': 0.19; 'trying': 0.21; '(i.e.,': 0.21; 'discussion': 0.22; "doesn't": 0.22; 'header:In-Reply-To:1': 0.22; 'code': 0.25; 'ignore': 0.26; 'explicitly': 0.29; 'sends': 0.29; 'error': 0.29; 'handling': 0.30; 'for,': 0.30; 'parent': 0.30; 'shooting': 0.30; 'signals': 0.30; '---': 0.31; "can't": 0.32; 'header:User- Agent:1': 0.33; 'that,': 0.33; 'to:addr:python-list': 0.34; 'calling': 0.34; 'forces': 0.34; 'posters': 0.34; 'operating': 0.35; 'however,': 0.36; 'actively': 0.36; 'subject:with': 0.36; '(by': 0.37; 'like,': 0.37; "there's": 0.37; 'signal': 0.38; 'received:org': 0.38; 'getting': 0.38; 'put': 0.38; 'fail': 0.39; 'prepared': 0.39; "it's": 0.40; 'to:addr:python.org': 0.40; 'collect': 0.61; 'ever': 0.65; 'anytime': 0.74; 'race': 0.77; 'child,': 0.84; 'anytime.': 0.91; 'wait,': 0.91
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=modelnine.org; s=modelnine1012; t=1325599014; bh=qxPoF6Q0lgzlv9R+zhuQPeSLpF2xFXbwpLmTvikO8JU=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=TKAkBpiTTz7Sowr3oZFzF/8ISqqLb9+kZHj+DNUTi7SKB3TcPiegPqAj8rpCcKp6v rCg+jS9chPPSjXKgP93x7oXiVUIbQEPXKg3gL221/acsCKgAVarff5LjOQJZNkOJmP 5biZmrNy8cILDAplbe1Uu8ubdhO/DJ2660+XDcbE=
Date: Tue, 03 Jan 2012 14:56:49 +0100
From: Heiko Wundram <modelnine@modelnine.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20111222 Thunderbird/10.0
MIME-Version: 1.0
To: python-list@python.org
Subject: Re: Avoid race condition with Popen.send_signal
References: <mailman.4323.1325545598.27778.python-list@python.org> <e2f96c71-544b-451e-9797-4d6b04438e6a@z17g2000vbe.googlegroups.com> <mailman.4348.1325593922.27778.python-list@python.org> <abf618bc-83d7-4f4b-b889-63e1ce4c42fa@y7g2000vbe.googlegroups.com>
In-Reply-To: <abf618bc-83d7-4f4b-b889-63e1ce4c42fa@y7g2000vbe.googlegroups.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-BeenThere: python-list@python.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion list for the Python programming language <python-list.python.org>
List-Unsubscribe: <http://mail.python.org/mailman/options/python-list>, <mailto:python-list-request@python.org?subject=unsubscribe>
List-Archive: <http://mail.python.org/pipermail/python-list>
List-Post: <mailto:python-list@python.org>
List-Help: <mailto:python-list-request@python.org?subject=help>
List-Subscribe: <http://mail.python.org/mailman/listinfo/python-list>, <mailto:python-list-request@python.org?subject=subscribe>
Newsgroups: comp.lang.python
Message-ID: <mailman.4352.1325599015.27778.python-list@python.org>
Lines: 33
NNTP-Posting-Host: 2001:888:2000:d::a6
X-Trace: 1325599016 news.xs4all.nl 6951 [2001:888:2000:d::a6]:48436
X-Complaints-To: abuse@xs4all.nl
Xref: x330-a1.tempe.blueboxinc.net comp.lang.python:18405

Am 03.01.2012 14:40, schrieb Adam Skutt:
> On Jan 3, 7:31 am, Heiko Wundram<modeln...@modelnine.org>  wrote:
>> Yes, it can be avoided, that's what the default SIGCHLD-handling
>> (keeping the process as a zombie until it's explicitly collected by a
>> wait*()) is for, which forces the PID not to be reused by the operating
>> system until the parent has acknowledged (by actively calling wait*())
>> that the child has terminated.
>
> No, you still can see ESRCH when sending signals to a zombie process.
> Code that sends signals to child processes via kill(2) must be
> prepared for the call to fail at anytime since the process can die at
> anytime.  It can't handle the signal, so it's treated as if it doesn't
> exist by kill(2) in this case.  However, you don't have to worry about
> sending the signal to the wrong process.

Getting an error on kill (which you can catch) is not about the race 
that the posters were speculating about (i.e., sending the signal to the 
wrong process), and that's what I was trying to put straight. The only 
advice that I wanted to give is:

1) before calling wait to collect the child, call kill as much as you 
like, and in case it errors, ignore that,

2) after calling wait, never, ever kill, and you don't need to, because 
you already know the process is gone.

There's no race possibility in this, _except_ if you alter handling of 
SIGCHLD away from the default (i.e., to autocollect children), in which 
case you have the possibility of a race and shooting down unrelated 
processes (which the discussion was about).

-- 
--- Heiko.