multithreading - Twisted:同时使用多个线程和进程

Question

Twisted 文档让我相信可以结合 reactor.spawnProcess() 等技术。和 threads.deferToThread()在同一个应用程序中， react 堆会在幕后优雅地处理这个问题。在实际尝试后，我发现我的应用程序死锁了。自己使用多个线程，或者自己使用子进程，一切都很好。

查看 react 堆源，我发现 SelectReactor.spawnProcess()方法只需调用 os.fork()不考虑可能正在运行的多个线程。这解释了死锁，因为从调用 os.fork() 开始。您将有两个具有多个并发线程的进程正在运行，并且谁知道使用相同的文件描述符做什么。

我的问题是，解决这个问题的最佳策略是什么？

我想到的是子类SelectReactor , 所以它是一个单例并调用 os.fork()只有一次，在实例化时立即。子进程将在后台运行并充当父进程的服务器(使用管道上的对象序列化来来回通信)。父进程继续运行应用程序并且可以根据需要使用线程。调用spawnProcess()在父进程中将被委托(delegate)给子进程，这将保证只有一个线程在运行，因此可以调用 os.fork()安全。

有没有人这样做过？有更快的方法吗？

Answer 1

What is the best strategy for solving this problem?

File a ticket (可能在 registering 之后)描述问题，最好使用可重现的测试用例(以获得最大准确性)。然后可以讨论实现它的最佳方式(或方式 - 不同的平台可能需要不同的解决方案)。

之前提出了立即创建子进程以帮助进一步创建子进程的想法，以解决围绕子进程收获的性能问题。如果这种方法现在解决了两个问题，它开始看起来更具吸引力。这种方法的一个潜在困难是 spawnProcess同步返回一个对象，该对象提供 child 的 PID 并允许向其发送信号。如果中间有中间进程，这需要更多的工作来实现，因为 PID 需要在 spawnProcess 之前传回主进程。返回。一个类似的挑战将是支持 childFDs参数，因为不再可能仅继承子进程中的文件描述符。

另一种解决方案(可能更骇人听闻，但实现挑战也可能更少)可能是调用 sys.setcheckinterval在调用 os.fork 之前使用非常大的数字，然后只在父进程中恢复原来的检查间隔。这应该足以避免进程中的任何线程切换，直到 os.execvpe发生，销毁所有额外的线程。这并不完全正确，因为它会使某些资源(例如互斥体和条件)处于不良状态，但您可以将这些资源与 deferToThread 一起使用不是很常见，所以也许这不会影响您的情况。