On Tuesday, September 12, 2017 at 1:35:43 AM UTC-4, Dave Cheney wrote: > > > > On Tuesday, 12 September 2017 15:23:56 UTC+10, Shivaram Lingamneni wrote: >> >> So this proves it: "happens-after Listener.Close()" is not a sufficient >> condition for being able to rebind the address. If another goroutine is in >> a Listener.Accept() call, the new bind must happen-after the return of both >> the Listener.Close() and the Listener.Accept() calls. >> > > Please see this code https://play.golang.org/p/j7ZxGbf4py >
Just checking we're on the same page. Do we agree that: 1. Between lines 20 and 21, the address is unsafe for re-bind because there is no ordering guarantee with respect to line 12 2. After line 21, the address is safe for re-bind because execution there must happen-after the return of both: a. the Close() call on line 20 (guaranteed because it executed previously in the same goroutine) b. the Accept() call on line 12 (guaranteed by the Wait() call on line 21) ? >> So the question is: are there any other conditions that can prevent >> Listener.Close() from resulting in close(2)? Is code that waits for the >> completion of both Close() and Accept() correct code? >> > > Not for network sockets. > Thanks! > > >> >> I don't understand the polling layer of the runtime to say whether it >> would be feasible for `Accept()` not to hold a reference during >> `WaitRead()` --- but it seems like that would be preferable. >> > > Once Accept has returned, the readLock is returned. Accept returns when it > receives a connection, or its underlying socket is closed via l.Close() > I'm asking about a potential change to the runtime that would eliminate the need to wait for Accept() to return. -- 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.
