Python:使用 `signal.alert` 超时 I/O 的缺点？

Question

using signal.alert有什么缺点使 Python I/O 超时？

我问这个问题是因为我发现 socket.settimeout 并不完全可靠[0]，并且我希望更好地控制不同操作的超时[1]。

因此，据我所知，缺点是:

• 增加了信号调用开销(但如果您正在执行 I/O，这应该不足为奇)
• 如果应用程序正在使用线程，它可能会变得“更复杂”(但如果已经使用线程，则生成监视器线程会更容易)

我错过了什么吗？

[0]:例如，慢速 DNS 查找不会超时。

[1]:例如，我希望某些读取的超时时间较短，而其他读取的超时时间应较长。

Answer 1

同时使用信号和线程时，您可能不会取得多大进展。来自 signal documentation :

... only the main thread can set a new signal handler, and the main thread will be the only one to receive signals (this is enforced by the Python signal module, even if the underlying thread implementation supports sending signals to individual threads)...

就缺点而言，解释器仅在解释器返回到主线程上下文中执行后才会调用信号处理程序。如果您有一个长时间运行的 C 扩展调用(SQL 查询、系统 I/O 操作等)，那么 SIGINT 和 SIGTERM 信号只有在返回后才会得到处理。如果您有严格的时间要求，那么这将无济于事。我提出的解决这个问题的最佳方法是将任务分配给子进程，使用 SIGKILL 在超时时终止子进程，然后创建一个替换子进程(自定义进程池)。

此外，如果您想使用信号处理程序作为通过异步引发的异常跳出代码块的方式，则无法保证程序状态的健全性。异常本身甚至可能最终在意想不到的地方引发。

为了满足您对套接字编程的需求，您应该从使用非阻塞 I/O 和 select 开始循环轮询是否准备就绪。或者您可以使用asyncore模块或非标twisted库抽象了很多这些细节。