什么时候需要为异步代码使用执行器？当我没有（但应该）时会发生什么？

Question

asyncio文档明确指出，asyncio代码不应直接调用阻塞代码，还指定了使用异步代码运行阻塞代码的方法：

不应直接调用阻塞（CPU绑定）代码。例如，如果函数执行CPU密集型计算1秒，则所有并发异步IO任务和IO操作将延迟1秒。

可以使用执行器在不同的线程中甚至在不同的进程中运行任务，以避免事件循环阻塞OS线程。

然而，这个描述对于在什么时候应该使用执行器不是很具体。很明显，“1秒钟的CPU密集型计算”是个问题，但是0.1秒会是个问题吗？还是0.01秒？

这些文档还提供了示例

def cpu_bound():
    return sum(i * i for i in range(10 ** 7))

作为在执行器中运行的东西（运行不到一秒钟）。

（虽然他们可能会使用这个作为使用线程vs进程的例子，但它仍然是我的意思的一个例子——如果它是范围（10**6），等等，我会在执行器中运行它吗？）

在这一答复中，有人指出：

大多数标准库由常规的“阻塞”函数和类定义组成。他们工作很快，所以即使他们“阻止”，他们也会在合理的时间内回来。

...

标准库函数和方法的加载速度很快，为什么要在单独的线程中运行str.splitlines（）或urllib.parse.quote（），而只执行代码并完成它会快得多？

但什么才算“合理时间”？我什么时候才能“执行代码并完成它”？

我的问题是：

1. 您如何确定需要执行人？
2. 如果代码“阻塞”太长，实际会发生什么？这种情况的迹象是什么

Answer 1

您如何确定需要执行人？

这个问题不是asyncio独有的。据我所知，还没有人提出一个精确的标准。

当前的做法与其他与性能相关的决策相同：通过结合常识和分析来确定。根据常识，可以在事件循环线程中调用urllib.parse.quote（），但使用BeautifulSoup解析任意大小的HTML文档可能不行。根据经验，协同程序可以包含您在Twisted这样的经典异步系统中轻松放置在回调中的代码。

如果你的代码“阻塞”太久，实际会发生什么？有什么迹象表明是这样的呢？

您会注意到延迟增加，吞吐量降低。

程序的预期延迟可能是决定何时开始使用执行程序的因素。还要注意，将某样东西交给执行者有其不可忽视的开销，所以你不想为所有事情都这样做，如果你为非常快的事情（例如归结为几个判决查找）。