X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:content-type; q=dns; s=default; b=V+F+Kg9
	3qvd3tuJ0RFg+37+nrdW59F05QGeb//jUkYNQPn+9HhQ/0J5HfskBhJ/0wIjBo/d
	7sa5pTce4NuCDfIfqesHmNimphVqbP80RDsCWjAQr1gLc9rKYHCxQpM5fZ6D10eL
	VCv7eWfIqDe5JFbNXx5JF3Yzjcu6nz400ST8=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:content-type; s=default; bh=TRKvMbhwkANCD
	vOIu6XrclSW5cg=; b=RRnikln7UaIle9LyUxpR6IvxcWfVZPdyRXbNEOfnH+IZL
	XM7156ujpquE6eDVScNS8vy/P14nakQDk61TKSJFC1EgsXI6AkQwYkDfKghSTIxd
	52aK/Oo0XNFK87AqdLxBqMHitdyGz3JIFMrm//xotBHCr/ix0TebPDf0LEyYT0=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Authentication-Results:	sourceware.org; auth=none
X-Virus-Found:	No
X-Spam-SWARE-Status:	No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=states, misspelled
X-HELO:	mail-wm0-f54.google.com
X-Google-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=kYXk22khO8xWo9rc7t0b0bYYwarbNXTp2M2Y2tRcLIw=; b=Xq3Ol0wUBeFd3vO6sF16OvQw3N/io6gDRTFvy6RpJh9VWhklNaHOovzZMuyBorpg+Q k44CvlO91xbxz6BvWok1p771vgsf+kxB3rQ4iQPiT2w/4JEXVERzBLvAvjwgJikMJ6UQ dSvjEz+UOVPk8tAtW7J37gPjQtDMstmuZ1uynsX0TUlT2rT4Y+t8lIEK8AdoKUmoAMh2 v4YWnRtWoVbrVdha6LE5xZgoEUwoRI4HPojfUo6sIp5GOZmy1uzfKoPezAKX/5AXWFAa HN4kMfw0nvk7tfMzQ7lQm6N94ltT6YvCQRVDkYmHYyml8uRywvJNvdGEmFNb25GMjfnL FBAw==
X-Gm-Message-State:	AEkoouuh3jC1TX0Oyq6dfY2kwn44ItWUliXHITh27lxZu6m93M177BiVaJ5W019Qf9q85CvIUbnrsQbQdUC5KQ==
X-Received:	by 10.25.15.167 with SMTP id 39mr2242077lfp.196.1470991468270; Fri, 12 Aug 2016 01:44:28 -0700 (PDT)
MIME-Version:	1.0
In-Reply-To:	<20160811141305.3em7tpcrxsushraa@calimero.vinschen.de>
References:	<CAOTD34Yv+namnsv+QNL2F-_c+W1-3ZdxZsgPQP8nxBEPNndcgw AT mail DOT gmail DOT com> <20160811141305 DOT 3em7tpcrxsushraa AT calimero DOT vinschen DOT de>
From:	Erik Bray <erik DOT m DOT bray AT gmail DOT com>
Date:	Fri, 12 Aug 2016 10:44:27 +0200
Message-ID:	<CAOTD34aZ=mmySsrnL=zEDRAXivJ1QcSdHsxxz2UyaABo4PXbWw@mail.gmail.com>
Subject:	Re: 2.5.1: kill(pid, sig) before waitpid() returns -1 for sig != 0
To:	cygwin AT cygwin DOT com, Erik Bray <erik DOT m DOT bray AT gmail DOT com>

On Thu, Aug 11, 2016 at 4:13 PM, Corinna Vinschen
<corinna-cygwin AT cygwin DOT com> wrote:
> Hi Eric,
>
> On Aug 11 11:51, Erik Bray wrote:
>> [...]
>> > Existing implementations vary on the result of a kill() with pid indicating an inactive process (a
>> > terminated process that has not been waited for by its parent). Some indicate success on such a
>> > call (subject to permission checking), while others give an error of [ESRCH]. Since the definition
>> > of process lifetime in this volume of POSIX.1-2008 covers inactive processes, the [ESRCH] error
>> > as described is inappropriate in this case. In particular, this means that an application cannot
>> > have a parent process check for termination of a particular child with kill(). (Usually this is done
>> > with the null signal; this can be done reliably with waitpid().)
>>
>> In response to the originally issue, this was fixed *specifically* for
>> the case of kill(pid, 0).  But my reading of the above is that kill()
>> should return 0 in this case regardless of the signal (modulo
>> permissions, etc.).  On Linux, for example, when calling kill with pid
>> of a zombie process the kernel will happily deliver the signal to the
>> relevant task_struct; it will just never be acted on since the task
>> will never run again.
>
> I'm not sure why cgf only fixed that for sig 0 at the time, since, as
> you noted, the text from POSIX-1.2008 does not state that this is
> *restricted* to sig 0.

Yep, my thoughts exactly.

>> The below (untested) patch demonstrates the change I'm suggesting,
>> though I don't know what other code, if any, might be involved in
>> this.
>
> The original patch laid the groundwork by making sure that there are
> two states, EXITED and REAPED.  Removing the explicit check for 0 is
> the right thing to do, afaics, so I tested and applied your patch as is,
> see
> https://cygwin.com/git/?p=newlib-cygwin.git;a=commitdiff;h=86f79af827729f3968d8b3b8f860ac29d200da0d

Thank you so much!  I think this is much better behavior.

(And thanks for the correction of my name--I'm used to it being
misspelled but rarely do people notice and correct :)

Best,
Erik

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

- Raw text -