time

Summary: Seems like we are running on a very weak fedora managed machine which resulted in Go changing non-blocking -> blocking Here is a detailed explanation: When you create a UDP connection in Go using net.ListenUDP(), Go's runtime registers the socket with its internal netpoller (an abstraction over epoll/kqueue). The netpoller requires sockets to be in non-blocking mode so it can efficiently multiplex I/O across many goroutines. Here's the problem: Go owns the socket: When you call timestamp.ConnFd(conn) to get the raw file descriptor, you're getting a reference to a socket that Go's runtime is actively managing. We want blocking mode: The code then calls unix.SetNonblock(connFd, false) to switch to blocking mode so that unix.Recvmsg() will block until a packet arrives. Conflict: But Go's netpoller may still be registered on that same fd, or Go might re-set it to non-blocking mode internally. This causes the socket to behave unpredictably - sometimes returning EAGAIN ("resource temporarily unavailable") when it should block. The fix - unix.Dup(connFd): Dup() creates a new file descriptor that points to the same underlying socket. This new fd: Is completely independent of Go's netpoller Can be safely set to blocking mode Won't be affected by Go's internal socket management The original fd (managed by Go) and the duplicated fd both refer to the same socket, but they have independent flags. So we can set blocking mode on our copy without interfering with Go's runtime. This is a common pattern when you need to do raw syscall I/O on a socket that was created through Go's net package. Reviewed By: vvfedorenko Differential Revision: D91676045