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: Terry Lambert <email@hidden>
- Date: Sat, 24 Nov 2007 17:52:19 -0800
On Nov 23, 2007, at 4:00 AM, Steve Checkoway <email@hidden> wrote:
On Nov 23, 2007, at 2: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.
This was pointed out last time Terry mentioned this, not that I've
ever read the standard. =)
<http://lists.apple.com/archives/Darwin-dev/2007/Jul/msg00068.html>
<http://lists.apple.com/archives/Darwin-dev/2007/Jul/msg00071.html>
That conversation was specifically about changing mtime on a file
where the metadata and file contents remain unchanged as a result of
specifying the O_TRUNC flag to an open call.
You have anecdotal support for your contention that we should not
short circuit the optimization of not calling the VNOP, and I haven't
seen a failing test case show up in either VSU or VSX to make me
change my mind about the optimizations correctness (yet). I still
think it's pretty weird for the build system you are using for your
Linux kernel depends on this behaviour, since it means there are some
FS types where this can never work. But if it were failing a test
case, it would get fixed more or less instantly.
-
As far as the current subject is concerned, the default cancel type is
PTHREAD_CANCEL_DEFERRED.
Assuming that stdio is attached to the slave side of a pty rather than
a serial console on an XServe or some third party dongle or whatever,
the the read is going to be blocked on the bsd wait channel "ttin",
with the thread in an interruptible state.
I think a strict interpretation of section 2.9.5 of System Interfaces
chapter 2 would permit, in the deferred case, the behaviour Per is
seeing. I agree, however, that in the async case, the thread should
wake up as if pthead_kill() had been called on it.
Unfortunately for me, I am on vacation, and as you can probably tell
by the spelling "corrections", I am using my phone to access email.
That means I can't fix the code by calling pthread_setcanceltype() to
asnc to see if the behaviour changes to the one Per wants.
If not, then it's a genuine bug in my book, but if so, I expect that
we will not change the behaviour of the deferred case. Otherwise, if
a fix was needed, we _may_ change the behaviour of the deferred case
in fixing the async case.
It would be handy if Per were to be a little more specific about his
execution environment, given that if stdin is not the slave side of a
pty, he is potentially in an uninterruptible state blocked in a buggy
device driver, rather than being interruptible in the tty code. It
would also be handy if he set the type to async and tried it again, so
that the person who will be catching that radar doesn't have to chase
all those things down.
Given this is a POSIX issue, and I pretty much own kernel "POSIXness",
but not threads, I'm pretty sure to be consulted on this when the bug
report gets out of DTS and over to the kernel team. Doing the checks
ahead of time and putting the data in the radar will keep it from
bouncing for more information.
-- Terry
_______________________________________________
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