|Anonymous | Login||2023-03-22 09:17 UTC|
|Main | My View | View Issues | Change Log | Docs|
|Viewing Issue Simple Details [ Jump to Notes ]||[ Issue History ] [ Print ]|
|ID||Category||Severity||Type||Date Submitted||Last Update|
|0000614||[1003.1(2008)/Issue 7] System Interfaces||Editorial||Clarification Requested||2012-09-24 22:08||2022-09-27 15:29|
|Priority||normal||Resolution||Accepted As Marked|
|Final Accepted Text||Note: 0005939|
|Summary||0000614: Behavior of close() as a cancellation point is unspecified|
For applications to correctly use cancellation, it's essential to know, when a function is cancelled, whether any or all of the function's side effects have taken place. For instance, if open is cancelled, it is important to know that a file descriptor was not allocated (which would inherently be a leak, since it's never returned to the caller). The standard handles this issue with the following text in XSH 2.9.5 under "Cancellation Points":
"The side-effects of acting upon a cancellation request while suspended during a call of a function are the same as the side-effects that may be seen in a single-threaded program when a call to a function is interrupted by a signal and the given function returns [EINTR]. Any such side-effects occur before any cancellation cleanup handlers are called."
However, this is not sufficient to define the behavior of close(), since:
"If close() is interrupted by a signal that is to be caught, it shall return -1 with errno set to [EINTR] and the state of fildes is unspecified."
(From the specification of close().)
This leaves an extremely dangerous situation where an application cancelled during close() cannot determine whether the file descriptor is still valid (and needs to be closed in the cleanup handler to avoid a leak) or already closed (in which case, closing it again in the cleanup handler would be dangerous because another thread could have raced to obtain a new file descriptor with the same numeric value).
My preference would be to add after the cited text from 2.9.5, "If cancellation is acted upon as a result of a call to close, no side effects of the close function shall have taken place." If this condition is too strong, perhaps language could be added to allow that the file descriptor may be in a state where it is not useful except to pass to close() again.
If there's an unwillingness to clarify the requirements on implementations, then "application usage" language should be added to the standard to make explicit the fact that applications which fail to block cancellation (with pthread_setcancelstate) around calls to close have unspecified behavior upon cancellation.
|This is probably a duplicate of 0000529, where the solution chosen there was to declare that close() must close the file descriptor unless it fails with EINTR, in which case it must leave the file descriptor open.|
|I agree that the final accepted text for 0000529 resolves this issue as well and matches my first choice of desired action. The fact that it does so suggests to me that the right decision was made on that issue, despite it being controversial at the time.|
|Then again, the text for 529 did not mention posix_close() as a cancellation point, which means it is incomplete, so there is still work to do for specifying how close() and posix_close() interact with cancellation.|
|It seems also to have failed to mention posix_close as an async-signal-safe function.|
On D2.1 page 483 line 16985 section 2.4.3 add posix_close() to the list of async-signal-safe functions.
On D2.1 page 506 line 17923 section 188.8.131.52 add posix_close() to the "shall" cancellation point list.
|2012-09-24 22:08||dalias||New Issue|
|2012-09-24 22:08||dalias||Status||New => Under Review|
|2012-09-24 22:08||dalias||Assigned To||=> ajosey|
|2012-09-24 22:08||dalias||Name||=> Rich Felker|
|2012-09-24 22:08||dalias||Organization||=> musl libc|
|2012-09-24 22:08||dalias||Section||=> XSH 2.9.5|
|2012-09-24 22:08||dalias||Page Number||=> unknwon|
|2012-09-24 22:08||dalias||Line Number||=> unknown|
|2012-09-24 22:17||eblake||Note Added: 0001375|
|2012-09-24 22:17||eblake||Relationship added||related to 0000529|
|2012-09-25 02:48||dalias||Note Added: 0001376|
|2012-09-25 15:51||eblake||Note Added: 0001377|
|2012-09-26 02:16||dalias||Note Added: 0001380|
|2012-11-28 17:37||nick||Relationship added||related to 0000632|
|2022-08-22 16:13||geoffclare||Note Added: 0005939|
|2022-08-22 16:13||geoffclare||Interp Status||=> ---|
|2022-08-22 16:13||geoffclare||Final Accepted Text||=> Note: 0005939|
|2022-08-22 16:13||geoffclare||Status||Under Review => Resolved|
|2022-08-22 16:13||geoffclare||Resolution||Open => Accepted As Marked|
|2022-08-22 16:14||geoffclare||Tag Attached: issue8|
|2022-09-27 15:29||geoffclare||Status||Resolved => Applied|
|Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group|