Goroutine Leak Profiles (go.dev)
29 points by torutofu 3 days ago
deathanatos 4 hours ago
I'm coming predominately from other languages, so it took me a hot minute to figure out what the various bug were.
• channels are by default "unbuffered", in that a send needs a waiting recv to actually do the send, and blocks until such. The addition of the buffer prevents the block & permits the goroutine to progress (and eventually exit, and thus, not leak) … so long as the buffer is sufficiently large enough.
• channels do not, AFAICT, realize when the receiver is gone, and will block indefinitely even when there is no receiver. (It is the same "chan" object, I think, in both sender/receiver / there is no distinction. So, the single object is never GC'd.)
• goroutines are not GC'd. (& the code doesn't/can't hold like, a reference or a handle to a goroutine / there is no "join" primitive.)
masklinn 3 hours ago
(2) has a bit more nuance to it: you can close channels… but the langage is designed for that to only be ok on single senders, a receiver can gracefully handle a closed channel (an iteration will just stop, a receive can use the 2-valued form to get the information), a sender will always straight up panic. Aka go channels are designed for fan-out.
And not closing channels is also considered idiomatic, per a tour of go:
> Channels aren't like files; you don't usually need to close them.