Correct cleanup in Google I/O 2013 concurrency talk?

agolangf · · 203 次点击    
这是一个分享于 的资源,其中的信息可能已经有所发展或是发生改变。
<p>I was watching <a href=""></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>

入群交流(和以上内容无关):加入Go大咖交流群,或添加微信:liuxiaoyan-s 备注:入群;或加QQ群:692541889

203 次点击  
加入收藏 微博
添加一条新回复 (您需要 登录 后才能回复 没有账号 ?)
  • 请尽量让自己的回复能够对别人有帮助
  • 支持 Markdown 格式, **粗体**、~~删除线~~、`单行代码`
  • 支持 @ 本站用户;支持表情(输入 : 提示),见 Emoji cheat sheet
  • 图片支持拖拽、截图粘贴等方式上传