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. What you wrote here, I'm trying to say it from the start. That kind of dup2 would be impractical to use, and why have *any* atomicity guarantee at all if you have to synchronize everything yourself anyway? But I could argue that the man is not explicit enough to disprove the wrong interpretation, even if it is "common sense". 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). -- 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/CAEvMKD95nk6cked9M8Z5HsRK9Vg_n4cmayb7H_J%2BeDzBRbmqog%40mail.gmail.com.
