Thanks for the reply. > Note that dup2() can only fail with EINTR if the new fd is currently open on > a "slow" device and the implicit close() fails due to being interrupted.
I understand the condition may be rare, but I still want to know the correct way to handle it. > In my experience it is usually an error if the new fd is currently in use > unless the new fd is 0, 1 or 2 . The Go programmer is not fully in charge of the FD namespace: libraries and the runtime can create new FDs at any time. Therefore, unless you are sure that newfd *is* in use and know exactly what it is, you are probably looking for trouble. > If you expect the new fd to be in use at the time of the dup2() it is usually > better, from the viewpoint of clarity, to incur the cost of an explicit > close() call. That seems very dangerous, especially in Go. If another goroutine opens a file between the close and the dup2, such open will likely reuse newfd which is about to be replaced. Then the second goroutine will have the wrong file and operate concurrently on it. Atomicity with close is the whole point of dup2. > So your question is really what to do if close() fails with EINTR and the > answer is retry. The man page [1] explicitly says that Linux close(2) should *never* be retried, not even on EINTR. As I mentioned, there are plans to change close to return EINPROGRESS, or even no error at all, instead of EINTR [2]. [1] http://man7.org/linux/man-pages/man2/close.2.html [2] 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/CAEvMKD-UCrAb7-BXy8Q6Bs4L%2Bn-MLptt5zS50XjQcy0FPSHsxw%40mail.gmail.com.
