|Anonymous | Login | Signup for a new account||2018-06-25 11:54 UTC|
|Main | My View | View Issues | Change Log | Docs|
|Viewing Issue Simple Details|
|ID||Category||Severity||Type||Date Submitted||Last Update|
|0000614||[1003.1(2008)/Issue 7] System Interfaces||Editorial||Clarification Requested||2012-09-24 22:08||2012-09-26 02:16|
|Final Accepted Text|
|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.
|Tags||No tags attached.|
|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.|
|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|
|Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group|