Correct cleanup in Google I/O 2013 concurrency talk?

<p>I was watching <a href="https://www.youtube.com/watch?v=QDDwwePbDtw">https://www.youtube.com/watch?v=QDDwwePbDtw</a> today, at about ~25 min he demos the &#34;move Fetch to it&#39;s own goroutine&#34; solution and claims that it&#39;s all safe, no leaks, cleaning up, etc.</p> <p>Isn&#39;t it plausible however that if you <code>Close()</code> the <code>Subscriber</code> that he makes that there&#39;s nobody ever who can listen on <code>fetchDone</code>, so the fetch goroutine blocks after it comes out of doing IO if the <code>for{select{}}</code> has already been cancelled?</p> <p>Just curious, of course it can be a mistake. I&#39;ve been doing go for years and still sometimes struggle to find patterns to clean up potentially leaked goroutines, rewatching this now because it came up at work and we were lamenting this talk not using <code>context.Context</code> because we&#39;d have liked to have seen it.</p> <hr/>**评论：**<br/><br/>nsd433: <pre><p>Note I didn&#39;t watch 25 minutes of video. I&#39;m just looking at what&#39;s in the video at 25:01. There it&#39;s not going to block because the fetchDone chan has capacity to hold the fetchResult. The result will be placed in the channel&#39;s queue, then the fetcher goroutine exits, and the channel and its queue get gc&#39;ed and we&#39;re done.</p></pre>Loves_Portishead: <pre><p>Right, it&#39;s a buffered channel, and presumably the GC catches them all. Well spotted, I three bytes makes all the difference <code>, 1</code>!</p></pre>nsd433: <pre><p>A channel with cap=1 for this kind of pattern is pretty standard. It&#39;s either that or a select with two cases: deliver the reply or notice a cancelation.</p></pre>