From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5886 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Cond var cancellation issue raised on Austin Group tracker issue #609 Date: Thu, 21 Aug 2014 13:35:45 -0400 Message-ID: <20140821173545.GA19756@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1408642572 21839 80.91.229.3 (21 Aug 2014 17:36:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 21 Aug 2014 17:36:12 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-5892-gllmg-musl=m.gmane.org@lists.openwall.com Thu Aug 21 19:36:06 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1XKWHG-0007UM-SU for gllmg-musl@plane.gmane.org; Thu, 21 Aug 2014 19:35:59 +0200 Original-Received: (qmail 3556 invoked by uid 550); 21 Aug 2014 17:35:58 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 3548 invoked from network); 21 Aug 2014 17:35:57 -0000 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:5886 Archived-At: Per note 0002350 on Austin Group tracker issue 609, there seems to be some question as to whether cancellation can be acted upon in pthread_cond_[timed]wait when the thread is formally already unblocked by a signal/broadcast: http://austingroupbugs.net/view.php?id=609#c2350 Presently, this situation can arise in musl, if after cancellation is acted upon, the signaling thread wins the race to set the waiter's state to SIGNALED rather than LEAVING. If it's deemed important to fix (either from a standards conformance standpoint, or just implementation quality), doing so should be easy: we can have pthread_cond_timedwait call setjmp, and the cancellation cleanup handler can call longjmp to abort cancellation if the state is SIGNALED. This adds a very small amount of overhead (one setjmp call) per wait. In the process-shared case, we can't reliably determine whether a signal occured here, so the process-shared case would just always longjmp out of cancellation (formally, it would observing a spurious wake just before cancellation would have happened). Rich