On Fri, Feb 28, 2020 at 12:41 PM <pboampo...@gmail.com> wrote: > 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. >
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. 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 . 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. If the new fd isn't in use then dup2() is atomic and will never fail with EINTR. So your question is really what to do if close() fails with EINTR and the answer is retry. However, in practice the only situation where EINTR will happen on close() is if the fd is open on a remote file system; e.g., a NFS mounted file system. Even that is extremely unlikely unless there is a problem with the network or remote file server in which case retrying is unlikely to succeed. -- Kurtis Rader Caretaker of the exceptional canines Junior and Hank -- 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/CABx2%3DD9RgrWhdt0XaetEyqmNzNkOLjqAGvfThdVGdeMKDsgBRA%40mail.gmail.com.
