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: Sat, 24 Nov 2007 11:08:40 -0500
On Nov 24, 2007, at 7:14 AM, Per Mildner wrote:
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].
Hmm. All of the other language in the standard concerning
cancellation points refer to entering ("reaching") a function that is
defined as a cancellation point, but you're right, this sentence does
cover the case where the function has already been called. It still
does not mandate that the request be acted upon immediately, as noted
specifically in the sentence after the one you quote: "However, if the
thread is suspended at a cancellation point and the event for which it
is waiting occurs before the cancellation request is acted upon, it is
unspecified whether the cancellation request is acted upon or whether
the cancellation request remains pending and the thread resumes normal
execution." This clearly assumes that (a) the cancellation request
does not supersede whatever else the function is doing, and (b)
function entry is the actual point where cancellation requests are to
be checked (which that case will be the *next* cancellation point).
"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.
I can see that interpretation, but there are still no constraints on
timeliness. Waiting around indefinitely until some other condition is
satisfied remains perfectly compliant with the standard, as does
completing the function without servicing the request and leaving it
to the next cancellation point (at least for deferred cancellation,
which is the default mode and the one your sample code uses).
Now, all that said, in the example code you posted I do think that the
read() from stdin (which is presumably a tty) should in fact be
interruptible--Terry's explanation of the interaction with the Mach
thread state should not apply, since simply hanging a read off of a
tty should not turn on TH_STATE_UNINTERRUPTIBLE. If you were
redirecting stdin from a file, though, I agree with Terry's diagnosis
(but in that case, presumably the read() would complete quickly, and
your thread would get cancelled).
--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