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=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
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
Content-Type: multipart/signed; micalg=pgp-sha256;	protocol="application/pgp-signature"; boundary="yEbVe0JFHWhrOjGA"
Content-Disposition: inline
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--