On Fri, May 16, 2025 at 04:39:57PM +0200, Vincent Lefevre wrote: > On 2025-05-16 09:05:47 -0400, Rich Felker wrote: > > FWIW musl adopted the EINPROGRESS as soon as we were made aware of the > > issue, and later changed it to returning 0 since applications > > (particularly, any written prior to this interpretation) are prone to > > interpret EINPROGRESS as an error condition rather than success and > > possibly misinterpret it as meaning the fd is still open and valid to > > pass to close again. > > If I understand correctly, this is a poor choice. POSIX.1-2024 says: > > ERRORS > The close() and posix_close() functions shall fail if: > [...] > [EINPROGRESS] > The function was interrupted by a signal and fildes was closed > but the close operation is continuing asynchronously. > > But this does not mean that the asynchronous close operation will > succeed. It always succeeds in the way that's important: the file descriptor is freed and the process no longer has this reference to the open file description. What might or might not succeed is: (1) other ancient legacy behaviors coupled to close(), like rewinding a tape drive. If the application cares how that behaves, it needs to be performing an explicit rewind *before* calling close, when it still has a handle on the open file so that it can respond to exceptional conditions, not relying on a legacy behavior like "close also rewinds" that's device-specific and outside the scope of any modern cross-platform standard. (2) deferred operations in unsafe async NFS setups. This is a huge mess with no real reliable solution except "don't configure your NFS to have unsafe and nonconforming behaviors in the pursuit of performance". Rich
