Documentation for sys::unix::fd::FileDesc::drop is confusing

[atomashpolskiy]

impl Drop for FileDesc {
    fn drop(&mut self) {
        // Note that errors are ignored when closing a file descriptor. The
        // reason for this is that if an error occurs we don't actually know if
        // the file descriptor was closed or not, and if we retried (for
        // something like EINTR), we might close another valid file descriptor
        // opened after we closed ours.
        let _ = unsafe { libc::close(self.fd) };
    }
}

While being strict to the letter of POSIX close(2), this comment looks to me as a little too abstract and therefore unnecessarily fear-inducing. Maybe it would make sense to expand it by saying that at least some of the major Unix-like systems do make sure to always close the FD, even when close() is interrupted, and that this is a pretty rare situation anyway, because it may happen only if a custom signal handler is set by the process. Maybe even provide some illuminating links like this epic discussion by POSIX workgroup. Making so might save time for people, who are not aware of the details of this issue, but nevertheless care enough about their FDs always being closed to start digging the Web for answers :) Thank you for reading.

[GrigorenkoPV]

Looks like this piece of code got moved over the last 4 years. Currently the comment in question resides here:

rust/library/std/src/os/fd/owned.rs

Lines 176 to 180 in cce6a6e

	// Note that errors are ignored when closing a file descriptor. The
	// reason for this is that if an error occurs we don't actually know if
	// the file descriptor was closed or not, and if we retried (for
	// something like EINTR), we might close another valid file descriptor
	// opened after we closed ours.

[Borgerr]

@rustbot claim