On Wed, Apr 18, 2018 at 7:25 PM, Steven Roth <st...@rothskeller.net> wrote: > > I just wrote some code for graceful restart of a web server, following > models available on the web. Unlike those models, my code didn't work. The > parent (old) web server refused to exit. The call to server.Shutdown > returned success, and the listener got closed, but the server.Serve call > never returned. After some differential debugging, I figured out this was > because of an unexpected side effect of the File method of the listener: it > puts the connection in blocking mode. In my case, I was calling that method > at the time I created the listener, which means the connection was in > blocking mode at the time server.Serve called its Accept method, so the > Accept never returned. When I moved my call to the File method to happen > later, everything started working properly. > > So now I'm curious: _why_ does calling File on net.TCPListener change the > behavior of the listener? Is that a bug that I should report?
Before about Go 1.9 or so the os package could not handle a non-blocking descriptor, so File had to change the connection to blocking mode in order to make it usable. Now, however, the os package does use nonblocking descriptors where possible. We could probably change the File method to use a nonblocking *os.File. Please do open an issue for that. 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. For more options, visit https://groups.google.com/d/optout.
