On Tuesday, 12 September 2017 17:56:19 UTC+10, Shivaram Lingamneni wrote: > > > > 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 >
It's more fundamental than that, until line 21 returns, you cannot observe the state of the other goroutine. Until there is a co-ordination event, the waitgroup Done/Wait, what the other goroutine is doing is unknown. > > 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) > After line 21 is is know than the goroutine calling Accept has exited. > > ? > > >>> 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. > I don't see why this change is necessary. Consider this example. https://play.golang.org/p/3WuTvGKrx5 -- 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.
