Ian, It is unclear how to interpret the POSIX specification regarding dup2 returning EINTR.
The POSIX specification [1] of dup2 says: "If the close operation fails to close *fildes2*, *dup2*() shall return -1 without changing the open file description to which *fildes2* refers." It appears that the authors assumed that close failing means that the close has not been executed and the file descriptor is still open. POSIX 2013 allows EINTR as return from dup2. However the same specification says for close [2]: "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." Now it is everybody's guess what the state of the old filedes2/newfd is after the hypothetical POSIX dup2 set errno to EINTR. On the Linux kernel close can indeed return EINTR. See the Linux man page for close [3]. However it is guaranteed that the file descriptor is actually closed, when EINTR is reported. The actual Linux kernel dup2 system call deals with the situation by ignoring errors of the close call and replaces the file descriptor no matter what. The situation is confused by the dup2 man page still stating that EINTR might be returned by dup2, which actually cannot happen. The Linux man page mentions that close on HP-UX returns EINTR and leaves the file descriptor open. On this system an EINTR errno set by dup2 can be handled by repeating the dup2 call. [1] https://pubs.opengroup.org/onlinepubs/9699919799/functions/dup2.html [2] https://pubs.opengroup.org/onlinepubs/9699919799/functions/close.html [3] http://man7.org/linux/man-pages/man2/close.2.html#NOTES -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/bf1e3df3-487a-4173-bba4-cbd2ddfde801%40googlegroups.com.
