Goroutines vs asyncio任务+ CPU绑定调用的线程池

Question

这些例程大致相当于python的asyncio任务，还有一个额外的特性，任何CPU绑定任务都被路由到ThreadPoolExecutor而不是添加到事件循环中（当然，假设我们使用没有GIL的python解释器）？

我错过了两种方法之间有什么实质性区别吗？当然，除了由于并发成为Go的一个组成部分而带来的效率和代码清晰度之外。

Answer 1

我想我知道答案的一部分。我试图总结一下我对asyncio任务和门店之间差异的了解，重要程度如下：

1）与asyncio不同，人们很少需要担心他们的goroutine会阻塞太久。 OTOH，跨goroutines的内存共享类似于跨线程的内存共享，而不是asyncio任务，因为goroutine执行顺序保证要弱得多（即使硬件只有一个内核）。

asyncio只会在明确的await，yield和某些事件循环方法上切换上下文，而Go运行时可能会切换更细微的触发器（如某些函数调用）。所以asyncio是完全合作的，而goroutines只是大多数合作（路线图表明他们将变得更不合作）。

一个非常紧密的循环（比如数值计算）仍然可以阻止Go运行时（以及它运行的线程）。如果发生这种情况，它将比python产生更少的影响 - 除非它出现在多线程中。 2）Goroutines对并行计算有现成的支持，这需要asyncio下的更复杂的方法。

Go运行时可以并行运行线程（如果有多个内核可用），所以它有点类似于在GIL-less python运行时下的线程池中运行多个asyncio事件循环，并且具有语言感知负载平衡器面前。

3）Go运行时会自动处理阻塞在一个单独的线程syscalls;这需要在asyncio下明确地完成（例如，使用run_in_executor）。

这就是说，就内存成本而言，goroutines非常像asyncio任务而不是线程。

Answer 2

我想你可以想象它在底下工作，当然。这并不准确，但足够接近。

但是有一个很大的区别：在Go中您可以编写直线代码，并自动为您处理所有I/O阻塞。您可以用简单的直线代码调用Read，然后Write和Read。使用Python asyncio，据我所知，您需要排队处理读取的函数，而不是只调用Read。