On Wed, Mar 4, 2020 at 6:20 AM Philip Boampong <pboampo...@gmail.com> wrote: > > On Sun, Mar 1, 2020 at 3:55 PM Ian Lance Taylor <i...@golang.org> wrote: > > > > If dup2 can 1) close newfd; 2) receive a signal before duping oldfd to > > newfd; 3) return EINTR leaving newfd closed, then dup2 requires > > considerable care in any multi-threaded program. It requires that if > > one thread is calling dup2, no other thread is permitted to open a > > file or socket or other file descriptor. That seems both unfortunate > > and unbelievable. I would like to see hard evidence before believing > > that kernel developers for any OS would create a system with such a > > bug. > > I'm not trying to convince you, I'm just showing the little > information I found (with links); you could have just said they are > wrong.
The links that I looked at were speculating about behavior, not demonstrating real behavior in kernels. I don't know how to judge whether those speculations about hypothetical behavior are correct or not. Many things are hypothetically possible. I'm just saying that before changing any code I would need to see actual evidence that some kernel behaves in that way, not just speculation that it might. If I missed something in those links, I apologize. > It seems that if I want to use dup2 at all, I have no other choice > than to believe that retry on EINTR is harmless (and I hope in every > sane system it is). In practice, if you don't use a FUSE file system, I bet that you will never see an EINTR error from dup2. That goes double for Go programs, as the Go runtime installs all signal handlers with SA_RESTART set. This isn't worth all that much, but using the os/exec package to start a new program will use dup2 to set up file descriptors. Those calls to dup2 do not retry on EINTR; any EINTR error will be reported back to the caller as an execution failure. I am not aware of any bug reports in which that actually happened. Ian -- 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/CAOyqgcVk7nqqyibgnYTLcHy%3D8EUtbO%3DM7c%2ByXUvqha6aAMwOAQ%40mail.gmail.com.
