‹ BackHN Continuity

Thread

Goroutine Leak Profiles

76 points · 6 comments · torutofu

  1. deathanatos · · focus · HN ↗
    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.)

    1. LukeShu · · focus · HN ↗
      "<-chan TYPE" is the receive end, "chan<- TYPE" is the send end, "chan TYPE" without an arrow can be used for either.

      close() on a chan is "indicate end-of-transmission"; you should only ever use it from the send end. There is no way to explicitly "close" the receive end.

      You can use `select` to do a non-blocking sends/receives, but yeah normal sends/receives are blocking.

      1. mitxela · · focus · HN ↗
        It's still the same object pointer. The GC can't force close a channel when it has no readable references left.
Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.