Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
x/build/internal/https: buggy synchronization in ListenAndServe #29941
This was going to be a drive-by comment on https://golang.org/cl/159698, but it's a separate (existing) bug and can be handled separately.
I suspect that we should only be making one of those two calls in the first place, in which case the need for the goroutine at all is very unclear.
It does start two goroutines in that case, but they don't use the same handler. The HTTPS goroutine uses the
This is true. However, in the most common use of
This also relies on the important property that both
As I understand, at least one goroutine is required to start an HTTPS and HTTP server at once. Two goroutines are used simply for symmetry, so both can write their error into the same
We could improve this, but the value is low. The
I can send a CL that fixes the goroutine leak and make the code more readable, but it'll still suffer from the property that when
In general, I prefer this code to live inside the command that's starting up the HTTP(S) servers, then it's easier to customize it for the exact needs of the program and not leak resources.
I would really rather we minimize cross-package reasoning like that: it makes package invariants much more difficult to see and maintain. Even in