Re: pthread_cancel and cancelation points still broken in Mac OS X 10.5 Leopard?
Re: pthread_cancel and cancelation points still broken in Mac OS X 10.5 Leopard?
- Subject: Re: pthread_cancel and cancelation points still broken in Mac OS X 10.5 Leopard?
- From: Amanda Walker <email@hidden>
- Date: Fri, 23 Nov 2007 11:53:53 -0500
On Nov 23, 2007, at 5:00 AM, Per Mildner wrote:
Cancellation passes VSTH test suite conformance testing, and is
therefore compliant with the letter of the specification.
I do not think any tests could verify conformance, for the same
reason no tests can verify the absence of bugs.
Conformance is determined by testing, pretty much by definition. Of
course, you could always argue that there is a bug in the test.
The following quote, from SUSv3, seems pretty clear to me in saying
that blocking is _not_ allowed to go on indefinitely:
"If a thread has cancelability enabled and a cancellation request is
made with the thread as a target while the thread is suspended at a
cancellation point, the thread shall be awakened and the
cancellation request shall be acted upon. "
That is, the blocking system call is not allowed to block forever.
I'm not sure that it follows quite as simply as that.
SUSv3 says that a cancellation point shall occur when a thread is
executing read(). However, it also specifies that how the target
thread handles the cancel request (including whether or not it can
defer it, and how long it may do so) is implementation dependent. It
specifically does *not* specify that "the blocking system call is not
allowed to block forever." There are no constraints on timeliness if
the cancel request is made *after the target thread has already
entered the function that is specified as a cancellation point*, which
is what it sounds like you are expecting (it does specify what happens
if the cancel request is made before the thread enters such a
function, which as you noted does work). SUSv3 further specifically
calls out an analogy between thread cancellation and signal delivery
(which is also deferred, possibly indefinitely, by uninterruptible
system calls).
Based on my re-reading of the standard, I think that if the committee
had meant to guarantee the behavior you are asking for, they would
have mandated it.
--Amanda
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden