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 17:45:37 +0100
On Nov 24, 2007, at 5:08 PM, Amanda Walker wrote:
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].
... 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,
I never claimed that but there is a big difference between not acting
immediately and never acting, i.e. blocking forever.
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 describes the case when the read() has finished its main work
_and is about to return to the caller_ so that the "thread resumes
normal execution". In this case read() is allowed to ignore the cancel
request (and the caller has no way to distinguish this case from when
the cancel request happened immediately after read() returned to the
caller).
This clearly assumes that (a) the cancellation request does not
supersede whatever else the function is doing,
Clearly the read() is allowed to perform its main task and ignore the
cancel request, provided read() is (soon) about to return to the
caller. This is not the case I am concerned with.
and (b) function entry is the actual point where cancellation
requests are to be checked (which that case will be the *next*
cancellation point).
(b) does not follow, at all. If nothing else this is evident from the
fact that on entry it is not yet the case that the "thread is
suspended" so the quoted sentence does not apply.
"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,
How can "waiting around indefinitely" be compliant with the SUSv3
requirements "shall be awakened" and "the cancellation request shall
be acted upon"
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
Apparently not, since the code does not terminate even though the
reading thread is cancelled.
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).\
Network file operations can take a long time and, e.g. sockets and
pipes can also block forever.
In any case, read() is just an example, the same kind of
implementation template seems to be used for many other supposedly
cancellable functions in the kernel. Nothing in this thread gives me
any reason to believe that they are not all violating the UNIX 2003
standard.
--Amanda
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