On Tuesday, 12 September 2017 13:40:04 UTC+10, Shivaram Lingamneni wrote: > > On Monday, September 11, 2017 at 11:17:01 PM UTC-4, Dave Cheney wrote: >> >> The already in use is probably coming from the TCP stack which waits a >> certain time before allowing the address to be reused. However I thought >> that the net package already used SO_REUSEADDR to avoid the delay in close >> to reopen. >> >> >>> The question I'm really asking is not so much how to write code that >>> works in practice (or, rather, appears to do so), but how to be certain (on >>> the basis of the specification and API documentation) that the code is >>> correct. >>> >> >> As written the code is correct. Once the listener is closed, you can >> reopen it, modulo TCP stack vagaries. >> > > The net package is indeed setting SO_REUSEADDR, which allows re-bind on > the address immediately after close(2). The problem is that close(2) is not > guaranteed to occur as a result of Listener.Close(), because of reference > counting of file descriptors. This is not an issue with the TCP stack; the > runtime is simply failing to issue the required system call. >
I've had a look through the code for the TCPListener and I cannot see where the reference count is being bumped by accept. As far as I understand the *netFD returned from Accept is unassociated with the *netFD that is bound to a listening socket. > > The original test case: > > https://gist.github.com/slingamn/f1f2ef4a8d004e67a9b0f27b698a5b13 > > demonstrates that the use of SO_REUSEADDR allows re-bind to succeed as > soon as the close(2) call has been issued (most likely, as James Bardin > suggested, at the point when the listener goroutine resumes execution after > the interruption of `Accept()`). > -- 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.
