Comment by AndyKelley
Comment by AndyKelley 21 hours ago
It's a bug to flush (fallible operation) in a destructor (infallible operation).
Comment by AndyKelley 21 hours ago
It's a bug to flush (fallible operation) in a destructor (infallible operation).
Why is he wrong?
Here's an excerpt from the close(2) syscall description:
RETURN VALUE close() returns zero on success. On error, -1 is returned, and errno is set to indicate the error.
ERRORS EBADF fd isn't a valid open file descriptor.
EINTR The close() call was interrupted by a signal; see signal(7).
EIO An I/O error occurred.
ENOSPC
EDQUOT On NFS, these errors are not normally reported against the first write which exceeds the available storage space, but instead against a subsequent
write(2), fsync(2), or close().
See NOTES for a discussion of why close() should not be retried after an error.
It's unfortunate that the original authors of this interface didn't understand how important infallibility is to resource deallocation, and it's unfortunate that NFS authors didn't think carefully about this at all, but if you follow the advice of the text you pasted and read the section about how you can't retry close() after an error, it is clear that close is, in fact, a fundamentally infallible operation.
I know you've thought carefully about these issues, but still it can't be that simple, can it? Closing a file or a socket is a fallible operation too.