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: Per Mildner <email@hidden>
- Date: Sat, 24 Nov 2007 13:14:14 +0100
On Nov 23, 2007, at 5:53 PM, Amanda Walker wrote:
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.
Tests can only detect non-conformance. Of course no test could verify
that the system fulfills the standard (or any other specification) in
all cases. This is even more true for timing-dependent behavior. If
nothing else it follows from the fact that tests only can test a
finite number of cases but the tested system has an infinite number of
possible states. Some states of the system will therefore remain
untested and could therefore hide non-conformant behavior.
For some timing related behavior it may be impossible to device a test
that does not sometimes incorrectly claim non-conformance. Testing for
cancel behavior may well be such a case, which may explain why the non-
conformant behavior may not have been detected by the UNIX 2003
conformance tests.
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 ...
I do not understand how you can interpret the above quote from SUSv3
as not putting a constraint on what should happen *after the target
thread has already entered the function that is specified as a
cancellation point*. As I wrote before, the relevant section from
SUSv3 says:
"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." [my emph].
"the thread is suspended at a cancellation point" means "the target
thread has already entered the function that is specified as a
cancellation point" (and is blocking there) and the mandated behavior
is "shall be awakened" and "the cancellation request shall be acted
upon" which certainly precludes blocking forever.
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
They did mandate the behavior I am asking for, in the text I quoted.
Regards,
_______________________________________________
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