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

- Raw text -