<story><title>Go concurrency patterns</title><url>http://talks.golang.org/2012/concurrency.slide#1</url></story><parent_chain></parent_chain><comment><author>sirclueless</author><text>How do goroutines get cleaned up? For example, in many of these examples they create a goroutine that is supposed to send a message over a blocking channel eventually. What if I use their &quot;select + time.After()&quot; pattern and the timeout hits and I return. Does the goroutine hang forever? Does it constitute a memory leak? We both hold the channel, so it can&apos;t get garbage collected, is Go smart enough to know there aren&apos;t any more readers and the goroutine + channel can get cleaned up?&lt;p&gt;Maybe to solve this I use a &quot;quit&quot; channel as they do. Do I need to worry about what happens if a quit message is never sent, or if two routines send one, or if the receiver is multiplexed and only one of many readers gets the message and cleans up correctly. It sounds like the whole malloc() and free() dance all over again, except this time I don&apos;t have any nice invariants to reason about such as &quot;Everything that gets malloc()ed needs to be free()d, exactly once&quot;. Instead I need to worry that everyone is playing nice and will terminate when asked, &lt;i&gt;and&lt;/i&gt; I need to remember to ask exactly once.</text></comment>
<story><title>Go concurrency patterns</title><url>http://talks.golang.org/2012/concurrency.slide#1</url></story><parent_chain></parent_chain><comment><author>Ezra</author><text>Video of rob giving the talk: www.youtube.com/watch?v=f6kdp27TYZs&lt;p&gt;Also, this makes use of the excellent &quot;Golang Present Tool&quot;, which makes most of the code on the slides executable.[1]&lt;p&gt;[1]: &lt;a href=&quot;http://godoc.org/code.google.com/p/go.talks/present&quot; rel=&quot;nofollow&quot;&gt;http://godoc.org/code.google.com/p/go.talks/present&lt;/a&gt;</text></comment>