delorie.com/archives/browse.cgi | search |
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:from:to:subject:date:message-id:content-type | |
:content-transfer-encoding:mime-version; q=dns; s=default; b=NB2 | |
mNPcvNa2aeXDNVYkfiebPZTdS+UlGrTBlmilP209BAxkr+8yj8lI/XF4bRaRHTb7 | |
fFiyDeF4JVFzGCtc18WmSoo+nzsCmXVWwOZ2jpsG44d0ro+H0rTkL9Q+uxcqBWFt | |
hBP0VIeOvQeYHPDcsGR01V92Z8hAPo8MXTl74/Fc= | |
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:from:to:subject:date:message-id:content-type | |
:content-transfer-encoding:mime-version; s=default; bh=fFDRy2ANn | |
+e+jTEuc+LwabUSEbM=; b=joLXuoyyPuRhbg59qqq85e30W0DeLQCiiLWkN/aqp | |
XZLE88dv0QjPz7wtsOZKgCrclibLV/nuljpwxjKt9QhtCWO8JxefvDguWuZIldVu | |
kblNhHGKFwN38ThnmEuyL+m27GDr13yMt88YXYHTXfSwUg9jm4g7FR7HEhmW90Rc | |
D0= | |
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=0.1 required=5.0 tests=BAYES_50,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 |
X-HELO: | gwo3.mbox.net |
X-USANET-Received: | from gwo3.mbox.net [127.0.0.1] by gwo3.mbox.net via mtad (C8.MAIN.4.02J) with ESMTP id 917TiksLG2816Mo3; Fri, 11 Sep 2015 18:11:32 -0000 |
X-USANET-Routed: | 5 gwsout-gwsd Q:gwsd |
X-USANET-Routed: | 3 gwsout-vs Q:bmvirus |
X-USANET-GWS2-Tenant: | electric-cloud.com |
X-USANET-GWS2-Tagid: | ECLD |
X-USANET-Source: | 165.212.120.254 OUT aeolus AT electric-cloud DOT com S1P5HUB3.EXCHPROD.USA.NET TLS |
X-USANET-MsgId: | XID515TiksLG7171Xo3 |
From: | John Carey <aeolus AT electric-cloud DOT com> |
To: | "cygwin AT cygwin DOT com" <cygwin AT cygwin DOT com> |
Subject: | pthread_kill: signals remain pending after target thread exits |
Date: | Fri, 11 Sep 2015 18:11:25 +0000 |
Message-ID: | <28F5B565B6F6424C87E4AC0DCC84316575D71070@S1P5DAG5C.EXCHPROD.USA.NET> |
MIME-Version: | 1.0 |
X-IsSubscribed: | yes |
X-MIME-Autoconverted: | from quoted-printable to 8bit by delorie.com id t8BIBq1d014660 |
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. To reproduce the issue: 1. Block signal number S. 2. Create thread T. 3. Send a signal with signal number S to thread T in particular (as opposed to the process in general). 4. After that signal has been sent, allow T to terminate without unblocking S or calling sigwait(). 5. Join T. 6. Create thread N. 7. Have N call sigwait() with a signal set that contains S. 8. Send to N a new signal with signal number S. 9. N never receives the new signal--instead, the new signal is discarded because the earlier signal remains pending. 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. For comparison, note that when performing the same steps on Linux (Ubuntu 14.04.3), N does in fact receive the second signal. Here is the relevant Cygwin source code, if I am understanding things correctly: - 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 - exceptions.cc : sigpacket::process : signal processing fails if it cannot find the target thread using init_cygheap::find_tls - sigproc.cc : pending_signals::add : discards new signals whose signal number matches that of a pending signal--regardless of target thread - 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) In my view it would be desirable if: - Pending signals targeting a particular thread would not outlast that thread. - 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. -- John Carey -- 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
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |