在clojure core.async go-loop中进行工作的方法有什么权衡？

Question

当我编写更多core.async代码时,出现的一个非常常见的模式是一个go-loop,它会在一系列通道上发生变化,并且会响应一条消息而做一些工作,例如:

(go-loop [state {}]
  (let [[value task] (alts! tasks)]
    ...work...
    (recur state))

我不觉得我理解我可以实际工作的各种方式的权衡,所以我想我会尝试在这里探讨它们.

• 内联或通过调用函数:这会阻止循环继续直到工作完成.因为它在go块中,所以不希望进行I/O或锁定操作.
• >!向工作人员监控的频道发送的消息:如果频道已满,则会通过停车来阻止该循环,直到该频道具有容量.这允许螺纹做其他工作并允许背压.
• >!消息:如果通道已满,则通过休眠运行go循环的线程来阻止.这可能是不合需要的,因为go thread是严格有限的资源.
• >!另一个go块中的消息:除非没有可用的线程,否则这几乎会立即成功.相反,如果通道已满并且正在慢慢消耗,则可能会在短时间内使线程系统匮乏.
• >!带有线程块​​的消息:类似于go块,但是消耗系统线程而不是去线程,因此上限可能更高
• 把!一则消息:目前尚不清楚这些权衡是什么
• 将来调用工作函数:将工作交给clojure代理池中的一个线程来做,允许go循环继续.如果输入速率超过输出速率,则会增加代理池队列而不受限制.

这个摘要是正确和全面的吗？

Answer 1

如果要完成的工作完全是CPU绑定的,那么我可能会在go块中内联,除非它是一个可能需要很长时间的操作,我希望go块继续响应其他消息.

通常,任何不阻塞,休眠或进行I/O的工作都可以安全地放入go块中,而不会对系统的吞吐量产生重大影响.

您可以使用>!将工作提交给工人或工作人员池.我几乎不会>!!在一个go块中使用,因为它可以阻止分配给运行go块的有限数量的线程之一.

当您需要执行I/O或可能长时间运行的计算时,请使用a thread而不是a go.这非常相似future- 它创建了一个真正的线程 - 但它返回一个类似的通道go.

put!是一种较低级别的操作,通常用于core.async的"边界",以将其连接到传统的基于回调的接口.put!里面几乎没有任何理由可以使用go.

core.async可以支持对线程创建方式的细粒度控制.我在博客文章" 使用core.async进行并行处理"中展示了一些可能性.