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: Mon, 26 Nov 2007 13:45:33 -0800
That interpretation of async vs. deferred renders async practically
useless, which I doubt is the intent.
As to when things have to be fixed or not, that's lawyer and release
schedule territory, way above my pay grade, and we do not discuss
release schedules here, ever.
Certification from my perspective has to do with passing the requisite
tests. If a test failure happens because a new test is added, we will
in general fix it or request a PIN (like both we and Tru64 UNIX got
for AST based signals already) ASAP.
Belaboring your point here isn't winning your bug any more attention
than it's already getting. Give us a break, we are all just getting
back from vacation.
Thanks,
-- Terry
On Nov 26, 2007, at 12:27 PM, Per Mildner <email@hidden> wrote:
I just added the following information to my bug report
(misspellings and all...):
I brought this up on the austin-group-l mailing list (Nov 23 2007,
Item 11231 "A question about cancellation points" on https://www.opengroup.org/sophocles/show_archive.tpl?listname=austin-group-l
). Presumably the Austin list members have more experience than most
in judging in matters related to SUSv3 conformance.
The consensus seems to be that the current Mac OS 10.5 behavior does
not conform to SUSvw3 and that:
<quote>
Mac OS X is just broken. 10.5 apparently passed the VSTH suite, which
simply means that the test suite has missed a few more relatively
obvious test cases.
</quote>
"In particular, no test suite can detect every possible way that an
implementation can be non-conforming."
<quote>
I would seem to me that Apple should correct the problem, once
reported, by its next Open Brand Certificate renewal date, which
si 18 May 2008.[sic]
</quote>
<quote>
Apple has an obligation to correct any reported non-conformities
"within the prescribed timescale", regardless of what may not be
detected by a test suite. (See
http://www.opengroup.org/openbrand/ .)"
</quote>
And, quoting from <http://www.opengroup.org/openbrand/>:
"If ... the non-conformance is not
corrected in the predefined timescale, then the Product
Registration, and the ability to use the trademark, will be lost."
The thread also points out that the behavior with
PTHREAD_CANCEL_ASYNCHRONOUS is irrelevant since:
<quote>
It would, in fact, be INCORRECT to call read(), or most other POSIX
functions, with asynchronous cancel enabled.
From POSIX, "The pthread_cancel( ), pthread_setcancelstate( ), and
pthread_setcanceltype( ) functions are defined to
be async-cancel safe. No other functions in this volume of POSIX.
1-200x
are required to be async-cancel-safe."
</quote>
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