From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 71204 invoked by alias); 21 Oct 2015 11:48:18 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 71157 invoked by uid 89); 21 Oct 2015 11:48:14 -0000 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 Received: from aquarius.hirmke.de (HELO calimero.vinschen.de) (217.91.18.234) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 21 Oct 2015 11:48:13 +0000 Received: by calimero.vinschen.de (Postfix, from userid 500) id 3EA9EA807CB; Wed, 21 Oct 2015 13:48:10 +0200 (CEST) Date: Wed, 21 Oct 2015 11:48:00 -0000 From: Corinna Vinschen To: cygwin@cygwin.com Subject: Re: pthread_kill: signals remain pending after target thread exits Message-ID: <20151021114810.GQ5319@calimero.vinschen.de> Reply-To: cygwin@cygwin.com Mail-Followup-To: cygwin@cygwin.com References: <28F5B565B6F6424C87E4AC0DCC84316575D71070@S1P5DAG5C.EXCHPROD.USA.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) X-SW-Source: 2015-10/txt/msg00338.txt.bz2 --yEbVe0JFHWhrOjGA Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 3358 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 Content-length: 819 -----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--