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=XWE7M5e33nyxdiUgSLSmECK4clzXkfMovrDs6IDD/PJTG6CugY2tQ
	6OeGA7EarSKVRIjHBixkUq5mdTQN2XMFTytD/vc8NDmhAwBvuIQR/OOPHL9iHOGC
	5IUwk3q6DP5S2oQ50bTkkfEIjP/gzdJmsBOs/zSGvk/modbEAuOGgM=
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=XcQFhQPqhQj9sWSFED8aQW4R8YE=; b=WtKZC8HyuiwVIrPZ4zaIvjNgrHE2
	hCiSPIEZ5r8nVqdLgtFzIuUi/3Lx6fImDvDh1ey/8jhAkj/LsIV8WKdlsIgCTjQo
	+zYixnNJnsA3bcg1qN92GHtgG25FR5p+PzDz1oJbGsVNbnlKoEdSK9Qeigw2zvMo
	84ZMlrl5ZuHbizQ=
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=-5.4 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2
X-HELO:	calimero.vinschen.de
Date:	Wed, 21 Oct 2015 13:48:10 +0200
From:	Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To:	cygwin AT cygwin DOT com
Subject:	Re: pthread_kill: signals remain pending after target thread exits
Message-ID:	<20151021114810.GQ5319@calimero.vinschen.de>
Reply-To:	cygwin AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
References:	<28F5B565B6F6424C87E4AC0DCC84316575D71070 AT S1P5DAG5C DOT EXCHPROD DOT USA DOT NET>
MIME-Version:	1.0
In-Reply-To:	<28F5B565B6F6424C87E4AC0DCC84316575D71070@S1P5DAG5C.EXCHPROD.USA.NET>
User-Agent:	Mutt/1.5.23 (2014-03-12)

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

Hi John,

On Sep 11 18:11, John Carey wrote:
> There seems to be a problem with pthread_kill: a pending signal
> targeting a particular thread prevents other threads from receiving
> signals sharing the same signal number--even after the original target
> thread exits and is joined.
>=20
> To reproduce the issue:
>=20
>   1. Block signal number S.
>=20
>   2. Create thread T.
>=20
>   3. Send a signal with signal number S to thread T in particular (as
>   opposed to the process in general).
>=20
>   4. After that signal has been sent, allow T to terminate without
>   unblocking S or calling sigwait().
>=20
>   5. Join T.
>=20
>   6. Create thread N.
>=20
>   7. Have N call sigwait() with a signal set that contains S.
>=20
>   8. Send to N a new signal with signal number S.
>=20
>   9. N never receives the new signal--instead, the new signal is
>   discarded because the earlier signal remains pending.

Yuk.

> BUT: It seems possible that N might inadvertently inherit the pending
> signal if its _cygtls instance happens to be allocated at the same
> address as the _cygtls instance of T.  It would be hard to predict
> when that would happen.  See the discussion of the source code, below.

The important thing here is to get rid of the pending signal.

> For comparison, note that when performing the same steps on Linux
> (Ubuntu 14.04.3), N does in fact receive the second signal.
>=20
> Here is the relevant Cygwin source code, if I am understanding things
> correctly:
>=20
>   - sigproc.cc : wait_sig : calls pending_signals::add, then tries to
>   process signals in the queue, but leaves queued any signal that
>   failed to process
>=20
>   - exceptions.cc : sigpacket::process : signal processing fails if it
>   cannot find the target thread using init_cygheap::find_tls
>=20
>   - sigproc.cc : pending_signals::add : discards new signals whose
>   signal number matches that of a pending signal--regardless of target
>   thread
>=20
>   - cygheap.cc : init_cygheap::find_tls : looks for a thread by the
>   address of its _cygtls instance, but a thread that has been joined
>   might happen to have had the same _cygtls address as a thread that
>   was subsequently created, and therefore pending signals for
>   terminated threads might sometimes be inherited by unrelated new
>   threads (or so it seems to me--as yet I have not managed to trigger
>   such a scenario)
>=20
> In my view it would be desirable if:
>=20
>   - Pending signals targeting a particular thread would not outlast
>   that thread.

Since you looked into the code anyway, do you have an idea how to
implement that?  For a start, do you have a simple testcase, only
the bare code needed to reproduce the issue?

>   - Multiple pending signals targeting different threads could
>   coexist, even if they shared the same signal number.  This happens
>   on Linux (Ubuntu 14.04.3), where I can generate two signals for two
>   different threads, then sleep for a bit in each target thread, and
>   finally have each thread receive its signal with sigwait()--neither
>   signal is lost during the sleeping period.

That requires to extend the handling for pending signals.  That's
a rather bigger task...


Corinna

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

--yEbVe0JFHWhrOjGA
Content-Type: application/pgp-signature

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

iQIbBAEBCAAGBQJWJ3t6AAoJEPU2Bp2uRE+gSfEP+JWeubzawVIHDNuVhvdhg7kQ
mzoZKMaD3KEBBCiuWT/SCZfmTZ9FJKCosnJim0E012NNi6AJY0In0VU4IOWKXZis
Is+Vid7vy6oWtaHshHFofg2YYZosN69JdmX25wR+Uc6VAi7gcbZh3LzDnkekGXIs
zZjuGQZouOiXgs92BcU6Vir84m7h+N9wPhXJM8YgRMzVfvnu5QKtn/s0EqtDzrAV
5/qLxjKrB+DOUoVX2KfUSGJFyPa1GQoon+E6ZnOga602q7c8qp3JVQmw/hek4Ki9
VZdpw5mDEoUzBX3ehN3qoND8dec+RrTFvDIuo9Oc16AgJ66Yy58onJyLX1Otdl+q
w+l7adLvD5hQaWYVBuf21jDFoRyp4rQjZRyPBZyIRn8f71HWqI6s95p61AvYiSLg
QufyjocPQriiR+FgCsCTISG4igxe8a6k29HkEe+lZjEkKSTCfO19O2xKSAKqTEEu
IaRYwkg0yxVWqc+ApoI/4l2EZS/xcFmP+aaRaoHZk7gvHn4x6OR3TdSFfRbnrpZw
uBE/Icqhjc36xJ1Hrwc19/811vxBDC+mAc1v+Iy4XFCJZ1uE4aLsJas8mcAuymHO
a2eAFL2oKoOA9yhnzOTkbCiLymitbacjt9fttKlT+MO4hqDxZRl1GJKUfH0DJ2Bc
shRViBBK6UALWbLskMc=
=gure
-----END PGP SIGNATURE-----

--yEbVe0JFHWhrOjGA--

- Raw text -