site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com 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. - -- Terry _______________________________________________ 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 4:00 AM, Steve Checkoway <s@pahtak.org> wrote: 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. This email sent to site_archiver@lists.apple.com