Goroutine Leak Profiles

Discussion (2 Comments)Read Original on HackerNews

deathanatos•about 2 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•about 1 hour 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.

Goroutine Leak Profiles

⚡ Community Insights

Discussion (2 Comments)Read Original on HackerNews