Thanks for the feedback. > "If the close operation fails to close fildes2, dup2() shall return -1 > without changing the open file description to which fildes2 refers." > "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."
The two statements you quoted are not necessarily contradictory: one is in the context of dup2(2), the other is in the context of close(2). In the context of dup2 they may be using the word "close" informally, without implying that a literal close(2) should be called internally. (Even though is seems inconvenient to actually have two different behaviors.) I wish the spec was more specific, but the dup2 prescription not to change the open file description to which fildes2 refers in case of error, seems to be intended as a guarantee that you can safely retry dup2 on EINTR. As you observed, by ignoring the result of the implicit close, Linux dup2 solves the problem from another angle. It deviates from the standard but it maintains compatibility, in the sense that it won't break if you wrap your dup2's into retry loops. If a dup2 can free filedes2/newfd and return EINTR, you are basically accepting that even ordinary signals (e.g. used by the runtime) can crash your dup2 in an irrecoverable way. I hope this can't be the case in a sane system (unless someone knows of a system which is actually affected). > The situation is confused by the dup2 man page still stating that EINTR might > be returned by dup2, which actually cannot happen. Yes, I was confused by that too. Also, neither dup2 nor close are mentioned in the signal(7) man page, therefore you can't tell if they are supposed to be affected by SA_RESTART or not. -- 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/CAEvMKD-GD4AUF_OO%2BYdRYnukof5k5WUqnkSOz%3Dueqk%2BSqzwUoA%40mail.gmail.com.
