Hi Geoff,
Thanks for your quick response.
Geoff Clare wrote:
Michael Kerrisk <mtk.lists@gmail.com> wrote, on 11 Nov 2008:
@ page 515 line 17842 to 17845 section XSH comment
Problem:
Lines 17842 to 17845 of draft 5.1 read as follows:
==
2.9.5.4 Async-Cancel Safety
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.
==
But the last sentence above seems to be directly contradicted by lines
62196 to 62197 of the sigwait() spec, which say:
==
After some consideration, threads were allowed to use semaphores
and sem_post() was defined to be async-signal and async-cancel-safe.
==
This problem seems to go right back to the original .1c threads
standard. At least, the same rationale appears in POSIX.1-1996
in section B.11.4.3 (Page 527 Line 6994).
Probably we should just remove "and async-cancel-safe".
That makes sense. Probably better to remove " and async-cancel", so that one
ends up with: "...was defined to be async-signal-safe."
And again there seems to be contradictory text in XRAT lines 118498 to
118499:
==
IEEE Std 1003.1-2001/Cor 1-2002, item XSH/TC1/D6/6 is applied, adding the
abort() function to the list of async-cancel-safe functions
==
This one is an obvious mistake in the wording of
1003.1-2001/Cor 1-2002, item XSH/TC1/D6/6. It added abort() to
the table of async-signal-safe functions in 2.4.3, but somehow
the word "cancel" got into the description of the change instead
of "signal".
I wondered if it was some such.
Thanks,
Michael
|