A NOTE has been added to this issue.
======================================================================
http://austingroupbugs.net/view.php?id=76
======================================================================
Reported By: msbrown
Assigned To: ajosey
======================================================================
Project: 1003.1(2008)/Issue 7
Issue ID: 76
Category: System Interfaces
Type: Clarification Requested
Severity: Comment
Priority: normal
Status: Under Review
Name: Mark Brown
Organization: IBM
User Reference:
Section: 2.9.5.4
Page Number: 515
Line Number: 17842-17845
Final Accepted Text:
======================================================================
Date Submitted: 2009-06-29 02:36 UTC
Last Modified: 2009-06-29 02:37 UTC
======================================================================
Summary: functions that are defined to be async-cancel safe
Description:
_____________________________________________________________________________
COMMENT Enhancement Request
Number 13
mtk.lists:xxxxxxxxx Bug in XSH (async-cancel-safe text)
(rdvk# 1)
Tue, 11 Nov 2008 11:14:48 -0500 (16:14
GMT)
______________________________________________________________________________
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.
==
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
==
Desired Action:
Not sure, sorry. The above texts seem to be contradictory, but I'm not
sure
how the contradiction is to be properly resolved.
======================================================================
----------------------------------------------------------------------
(0000131) msbrown (manager) - 2009-06-29 02:37
http://austingroupbugs.net/view.php?id=76#c131
----------------------------------------------------------------------
In sigwait() RATIONALE
> ==
> After some consideration, threads were allowed to use semaphores
> and sem_post() was defined to be async-signal and async-cancel-safe.
> ==
Remove " and async-cancel", so that the resulting text
ends up with: "...was defined to be async-signal-safe."
This problem seems to date 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).
> 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
> ==
Change async-cancel-safe functions to async-signal-safe functions to
This one is a 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".
|