Hi,
I'm updating the manual pages for POSIX.1-2024, and have some doubts
about close(2). The manual page for close(2) says (conforming to
POSIX.1-2008):
The EINTR error is a somewhat special case. Regarding the EINTR
error, POSIX.1‐2008 says:
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.
This permits the behavior that occurs on Linux and many other
implementations, where, as with other errors that may be re‐
ported by close(), the file descriptor is guaranteed to be
closed. However, it also permits another possibility: that the
implementation returns an EINTR error and keeps the file de‐
scriptor open. (According to its documentation, HP‐UX’s close()
does this.) The caller must then once more use close() to close
the file descriptor, to avoid file descriptor leaks. This di‐
vergence in implementation behaviors provides a difficult hurdle
for portable applications, since on many implementations,
close() must not be called again after an EINTR error, and on at
least one, close() must be called again. There are plans to ad‐
dress this conundrum for the next major release of the POSIX.1
standard.
TL;DR: close(2) with EINTR is allowed to either leave the fd open or
closed, and Linux leaves it closed, while others (HP-UX only?) leaves it
open.
Now, POSIX.1-2024 says:
If close() is interrupted by a signal that is to be caught, then
it is unspecified whether it returns -1 with errno set to
[EINTR] and fildes remaining open, or returns -1 with errno set
to [EINPROGRESS] and fildes being closed, or returns 0 to
indicate successful completion; [...]
<https://pubs.opengroup.org/onlinepubs/9799919799/functions/close.html>
Which seems to bless HP-UX and screw all the others, requiring them to
report EINPROGRESS.
Was there any discussion about what to do in the Linux kernel?
Have a lovely night!
Alex
--
<https://www.alejandro-colomar.es/>
Attachment:
signature.asc
Description: PGP signature
