On Sat, Feb 29, 2020 at 4:35 PM Uli Kunitz <uli.kun...@gmail.com> wrote: > > My reading of the Linux kernel sources (5.3) is that dup2 will never return > -EINTR.
Thanks, good to know. > But you will have to program the loop around the syscall anyway, because > Linux may return EBUSY, which happens if the new fd has been allocated by > somebody else, but has not finished the initialization of the descriptor. In my use cases I don't think I need to worry about EBUSY because newfd is always 0/1/2 which should be already fully open. Someone argues that it doesn't make much sense to retry dup2 on EBUSY, because it's an indication of a serious problem (you are trying to swap a file under another goroutine's feet), see [1]. Also an open can take any amount of time to complete (e.g. a fifo) and it doesn't seem like a good idea to busy-waiting for it in a loop. > So if you want to write a safe program, you have to implement the loop around > dup2 checking for EBUSY. It cannot harm to check for EINTR as well. Whether it cannot harm is what I'm trying to find out. If newfd gets closed then a retry loop is racy, see my previous messages. [1] https://stackoverflow.com/questions/23440216/race-condition-when-using-dup2 -- 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_oymSAXEZL0iY0F4U_iS7Ggi5SreMKGcXxfXk02LDk7A%40mail.gmail.com.
