将 concurrent.futures.Future 与 greenlets/gevent 一起使用

Question

我有一个 python 库，它通过多播执行异步网络，它可能会从其他服务中获得回复。它通过返回将捕获回复的Future 来隐藏肮脏的工作。我正在将此库集成到现有的 gevent 应用程序中。调用模式很简单：

future = service.broadcast()
# next call blocks the current thread
reply = future.result(some_timeout)

在后台，concurrent.futures.Future.result() 使用 threading.Condition.wait()。

使用猴子补丁的线程模块，这看起来很好且安全，并且不会阻塞 greenlets。

在这里或混合gevent 和concurrent.futures 时有什么理由担心吗？

Answer 1

嗯，据我所知，futures 没有记录在threading.Condition 之上工作，gevent 也没有记录可以安全地修补futures。因此，理论上，有人可以编写一个 Python 实现来破坏gevent。

但实际上呢？很难想象这样的实现会是什么样子。您显然需要某种同步对象来使Future 工作。当然，您可以使用Event、Lock 和Rlock 而不是Condition，但这不会对gevent 造成问题。实现可能会破坏事情的唯一方法是直接转到 pthreads/Win32/Java/.NET/whatever 同步对象，而不是使用 threading 中的包装器。

如果发生这种情况，你会如何处理？好吧，futures 是用纯 Python 实现的，它是非常简单的 Python，并且有一个功能齐全的 backport 可以与 2.5+/3.2+ 一起使用。所以，你只需要抓住那个反向端口，把concurrent.futures换成futures。

所以，如果你正在做一些古怪的事情，比如部署一个可以在无人值守的情况下运行 5 年的服务器，并且它的 Python 可能会在其下反复升级，那么我现在可能会安装 backport 并改用它。

否则，我只需在适当的位置记录假设（以及解决方法以防万一），然后使用 stdlib 模块。