You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It's, uh... not wrong? If you assume that the only connections that will be accepted come from the program itself (which AFAICT is a valid assumption in the faked world of the Playground), then it really is deadlocked.
So the TL;DR of this was that I was chatting with someone on my phone, and thought http.ListenAndServe() was a nice example to show "this is one of the things that make Go nice!". Then clicked the "run example", and saw the ugly trace (which likely wasn't the intent of that example, and very likely will confuse users).
Your updated example looks good (perhaps even better, as it's a more complete example); slightly concerned if the added complexity will distract from the http.ListenAndServe() topic itself.
FWIW, I think that update may actually be racy. (I'm not sure what it happens to do if the http.Get goroutine executes before the ListenAndServe goroutine has opened the socket.)
If you're going to use ListenAndServe for an application that has actual tests, you'll probably have to write a spin-loop that waits for the server to come up before starting the tests. IMO it's much more ergonomic to just use net.Listen and http.Serve separately, so that you can establish the Listenerbefore starting the requests to it.