mirror of
https://github.com/rust-lang/rust.git
synced 2025-02-02 10:04:23 +00:00
Rollup merge of #133330 - RalfJung:close, r=the8472
library: update comment around close() r? `@the8472`
This commit is contained in:
commit
bbc4cbe3e2
@ -173,16 +173,17 @@ impl Drop for OwnedFd {
|
||||
#[inline]
|
||||
fn drop(&mut self) {
|
||||
unsafe {
|
||||
// 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.
|
||||
// However, this is usually justified, as some of the major Unices
|
||||
// do make sure to always close the FD, even when `close()` is interrupted,
|
||||
// and the scenario is rare to begin with.
|
||||
// Helpful link to an epic discussion by POSIX workgroup:
|
||||
// http://austingroupbugs.net/view.php?id=529
|
||||
// Note that errors are ignored when closing a file descriptor. According to POSIX 2024,
|
||||
// we can and indeed should retry `close` on `EINTR`
|
||||
// (https://pubs.opengroup.org/onlinepubs/9799919799.2024edition/functions/close.html),
|
||||
// but it is not clear yet how well widely-used implementations are conforming with this
|
||||
// mandate since older versions of POSIX left the state of the FD after an `EINTR`
|
||||
// unspecified. Ignoring errors is "fine" because some of the major Unices (in
|
||||
// particular, Linux) do make sure to always close the FD, even when `close()` is
|
||||
// interrupted, and the scenario is rare to begin with. If we retried on a
|
||||
// not-POSIX-compliant implementation, the consequences could be really bad since we may
|
||||
// close the wrong FD. Helpful link to an epic discussion by POSIX workgroup that led to
|
||||
// the latest POSIX wording: http://austingroupbugs.net/view.php?id=529
|
||||
#[cfg(not(target_os = "hermit"))]
|
||||
{
|
||||
#[cfg(unix)]
|
||||
|
Loading…
Reference in New Issue
Block a user