Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
net/http: consider making Transport clean up after itself #24739
If a Transport falls out of scope with idle connections, it will leak.
This is surprising for users (for example #24719), and obscure/inconsistent.
Implementing a finalizer would require making sure that all blocked goroutines don't keep pointers to the Transport itself, which might be hard.
Some previous discussion at #16005.
I don't want this to be a crutch that people rely on, since finalizers are not reliable in general.
If we do use a finalizer, I'd only use it to warn.
But I don't even think it'd be possible to split Transport in two parts as @bcmills had suggested, without breaking API.
I've instead considered some (probably optional) thing that you can enable in your binary while debugging that looks at active goroutines and finds leaked Transports, perhaps using @randall77's new viewcore/heap inspection stuff, to figure out which Transports are only referencing themselves. hand wave
But given that it'd be a fair bit of work either way, and we'd only use it to warn, it's kinda low priority.
Something to consider more for Go2, perhaps.
I think it would be possible to split up the object without breaking the API, but it would make the internals a bit funny. Basically, at the first
They seem to mostly not be the sort of functions likely to refer back — and if they're only involved in the dialing / handshake path, they might not need to be reachable from idle-connection goroutines anyway. (That is, we might not need to copy those fields to the internal object.)