On Fri, Feb 28, 2020 at 8:27 PM Philip Boampong <pboampo...@gmail.com> wrote: > > 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.
It does not make sense to use dup2 if you are not in control of the FD namespace. In order to use dup2 you need to specify the new FD. If that FD might be concurrently opened by some other package, or by the runtime, then you can not use dup2 safely. That is true regardless of whether dup2 returns EINTR or not. This doesn't mean that Go program can never use dup2. The runtime will only open a file descriptor when requested. You can avoid packages that open descriptors at unpredictable times. You can use locks or channels to ensure that when you call dup2 nothing else can be opening a file. Of course, this does mean that a large Go program with uncontrolled dependencies may not be able to call dup2 safely. The same is true of a multi-threaded C program. It's in the nature of the system call. Is this a theoretical question or one that arises from real code? The dup2 system call has fairly specialized uses. It's unusual for a general purpose program to need to call it. 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/CAOyqgcU_QLy2Sb2FUq4%3DOEEp7Pc0zUg89qrYwRrPak9daDu7%2BA%40mail.gmail.com.
