(I've asked the same question already, but probably in the wrong thread, sorry for the repost.)
What to do on EINTR from syscall.Dup2 (Linux)? 1) It never happen. 2) Retry. 3) Take it as irrecoverable. 4) Take it as success. I know this is more of an OS question, but it all started with the asynchronous preemption announcement, and I don't know where else to get help. In the signal(7) man page, dup2 is neither mentioned in the "affected by SA_RESTART" list, nor in the other list. Is it affected or not? According to [1][2], dup2 can close newfd and still fail, therefore it should *never* be retried because a retry would cause a dangerous race. This would mean that a signal during dup2 (nothing out of the ordinary) would produce an irrecoverable condition! The man page says that close+dup is done "atomically", but it isn't clear whether "close and fail" is a possibility or not. Someone also hypothesizes that EINTR from dup2 can actually mean success, because it comes from the implicit close(2) and EINTR from close is not a failure indication on Linux (there are plans to change it to EINPROGRESS), see also [3][4]. I hope someone can shed some light on this, thanks. [1] https://github.com/libuv/libuv/issues/462 [2] https://www.python.org/dev/peps/pep-0475 [3] https://stackoverflow.com/questions/15930013/can-dup2-really-return-eintr [4] https://lwn.net/Articles/576478 -- 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/ec07c211-4b69-4791-9e8f-1b4122130424%40googlegroups.com.
