[<prev] [next>] [day] [month] [year] [list]
Date: Thu, 21 Aug 2014 13:35:45 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Cond var cancellation issue raised on Austin Group tracker issue #609
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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
