在时雄docs中关于正常关闭的页面底部，它建议了一种简洁的方法，即使用mpsc通道等待任务完成，然后等待通道关闭，当每个发送方都被丢弃时，就会发生这种情况。
与tokio::join!相比，在您期望完成的任务上，它提供了哪些优势？channels方法确实意味着，如果您不关心结果的话，您可以避免为所有任务创建句柄。但不清楚它是否会使额外的drop(tx)更容易阅读代码，并且您需要向每个任务传递额外的_sender: Sender<()>参数。
它是否只是归结为风格或有另一个原因，青睐渠道在这里？
1条答案
按热度按时间2skhul331#
我认为渠道方法的优势在于它更易于组合;更容易通过一些复杂的系统进行分发。
在他们的例子中-“产生10个任务，然后使用一个mpsc通道等待它们关闭”-这10个任务就在那里，但是如果一些任务是动态产生的，稍后产生的，或者在某个子系统中“私下”产生的呢？
所有这些都可以通过将发送方克隆传递给所有部分来处理。接收方保持器不需要知道所有这些部分是什么。
并且需要向每个任务传递一个额外的
_sender: Sender<()>参数。注意，在比示例更复杂的情况下，发送者可以在任务无论如何都需要的某个上下文对象中携带，发送者也不必克隆自己;包含某个包含发送者的上下文结构的
Arc也可以。