On Friday, February 28, 2020 at 9:41:39 PM UTC+1, pboam...@gmail.com wrote: > > (I've asked the same question already, but probably in the wrong thread, > sorry for the repost.) > > 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. > > In the signal(7) man page, dup2 is neither mentioned in the "affected by > SA_RESTART" list, nor in the other list. Is it affected or not? > > According to [1][2], dup2 can close newfd and still fail, therefore it > should *never* be retried because a retry would cause a dangerous race. > This would mean that a signal during dup2 (nothing out of the ordinary) > would produce an irrecoverable condition! > The man page says that close+dup is done "atomically", but it isn't clear > whether "close and fail" is a possibility or not. > > What about using fcntl with F_DUPFD? http://man7.org/linux/man-pages/man2/fcntl.2.html It will "Duplicate the file descriptor fd using the lowest-numbered available file descriptor greater than or equal to arg"
It does not have the problems of dup2 where you can use an already in use fd, and unlike dup you can specify where the new fd should be allocated. Manlio -- 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/b70efd8a-c078-4835-a4be-ea6a0c1eb7a4%40googlegroups.com.
