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:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=T5LcJfh4bjE9Way9S1bG4ZdlqNvVl845E+N1PRTf4vCBxg/rKLLnH
	pW37s3pwcmzW0gYz/n5jNh2PFC7TnBWIsXhRznq7g0agTsqVl83YLJq756ntRobZ
	VmgWx14jlpTd+EjSkKhJLwY5bmNOpK34NVSpEloD5VcD/S4AQZ0qXw=
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:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; s=default;
	bh=WYTgsaiPBXTc4DgSe8fN5+/Xmxo=; b=lODjyE7ET3FyInkYzmtkV7Wv/b/n
	Q+U/fZR9mGgLZ0Bpo8srDJYgr35ZOAmj8k3cZr6KIsIZ9aM3Mk7/LHlEhOHz9BTf
	lvH9F5lxhqNDbmDxAjyrB8mvTrlyZ/fNgyg/5eEZfOCYWWJFnsNm3euv4P6Skon7
	hqUQuP+oVIvu4Fw=
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=-94.9 required=5.0 tests=AWL,BAYES_00,GOOD_FROM_CORINNA_CYGWIN,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_BRBL_LASTEXT,RCVD_IN_PBL,RCVD_IN_SORBS_DUL,RDNS_DYNAMIC autolearn=ham version=3.3.2 spammy=states
X-HELO:	calimero.vinschen.de
Date:	Thu, 11 Aug 2016 16:14:42 +0200
From:	Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To:	cygwin AT cygwin DOT com, Erik Bray <erik DOT m DOT bray AT gmail DOT com>
Subject:	Re: 2.5.1: kill(pid, sig) before waitpid() returns -1 for sig != 0
Message-ID:	<20160811141442.v4yuja3ic5y6lit4@calimero.vinschen.de>
Reply-To:	cygwin AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com, Erik Bray <erik DOT m DOT bray AT gmail DOT com>
References:	<CAOTD34Yv+namnsv+QNL2F-_c+W1-3ZdxZsgPQP8nxBEPNndcgw AT mail DOT gmail DOT com> <20160811141305 DOT 3em7tpcrxsushraa AT calimero DOT vinschen DOT de>
MIME-Version:	1.0
In-Reply-To:	<20160811141305.3em7tpcrxsushraa@calimero.vinschen.de>
User-Agent:	Mutt/1.6.2-neo (2016-07-23)

--vxcmwr4hcvfmkzmb
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Aug 11 16:13, Corinna Vinschen wrote:
> Hi Eric,

Oops, Eri*k*.


Sorry,
Corinna

>=20
> On Aug 11 11:51, Erik Bray wrote:
> > [...]
> > > Existing implementations vary on the result of a kill() with pid indi=
cating 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 pr=
ocesses, 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 wit=
h kill(). (Usually this is done
> > > with the null signal; this can be done reliably with waitpid().)
> >=20
> > 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.
>=20
> 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.
>=20
> > 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.
>=20
> 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=20
> https://cygwin.com/git/?p=3Dnewlib-cygwin.git;a=3Dcommitdiff;h=3D86f79af8=
27729f3968d8b3b8f860ac29d200da0d
>=20
>=20
> Thanks,
> Corinna
>=20
> --=20
> Corinna Vinschen                  Please, send mails regarding Cygwin to
> Cygwin Maintainer                 cygwin AT cygwin DOT com
> Red Hat



--=20
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

--vxcmwr4hcvfmkzmb
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJXrIhSAAoJEPU2Bp2uRE+gUbUP/iO5guIAkTtbYJtr3yZJmpOj
ise/CYCV38PO5VgsEAGdGfl5d051XHsmZ+K2cbousXbZkCJvjLfc6zQkSFNDq/XQ
2GbunZgD4ZJQF6v0Nv3VXIempK8uTL3QLHwnoTnukzJixn5ZGP1aoNLoskkkmIfX
u8uuAYV0M0m4HotTeqm1C5GSL3XEme+g2R0mXyqM60Yb2tnetZysxtLxSdfCx1BX
MjwUpcThMRAx6Mt+FzJWb64rT4mt9zGG51Z03uKEQbvBgbtDu1DngOzt0a7VRVzE
SWh2MnaZ6J7MfnlzB1X2V8CV9DQg48SQ9VETSbq2IBfjf6ReAnos9qFlWnRQOXnB
Ap0iEvSjorBbqxQgAquUHKHlJMUY8REa1sxhqpp23WbiaBXVQ/vI3rl2bPGxhy/0
7oO4QK05NkJbyQ/JHUXdjIzgqjcw6JjBHL/6cApog1KwT03rCnCoPzcwfkSCnJsd
77hNXMEvrVgtVd/gkHJ6tDQxdnLqmLC+pEXQO/SrPwgU+SBkQgpl6Brhih1Odr7U
MFH75lVLRu219h2SHHhoAEogAtzFzlAl9eRIbmsMyG2DwPjzgXGsO53GCl0XKpbR
H9uS2ov2KylEqYhR5iU5YtWTSDWW6FhA8TO2qpaYWN7CM5O4ZqyJYsS9wyv/kBkz
SqVjl2pH38gb/rs//Qi9
=wZHJ
-----END PGP SIGNATURE-----

--vxcmwr4hcvfmkzmb--

- Raw text -