site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com Cancellation passes VSTH test suite conformance testing, and is therefore compliant with the letter of the specification. I'm not sure that it follows quite as simply as that. --Amanda _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... On Nov 23, 2007, at 5:00 AM, Per Mildner wrote: 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. 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. This email sent to site_archiver@lists.apple.com