python - 为什么 Python 的 queue.Queue.get() 允许从超时中提前返回？

Question

更新:这个问题是基于 Queue.get() 实际行为方式的错误心理模型，这是由一些稍微模棱两可的文档引起的，但主要是由 timedelta.total_seconds 的错误、手动实现引起的()。我在试图证明原始答案不正确时发现了这个错误。现在 timedelta.total_seconds() 由 Python 提供(自 2.7 起)，我将开始使用它。

抱歉造成混淆。

---

这不是“为什么我的代码不运行？”问题，而是“这个设计决策背后的动机是什么？”

从 2.3 开始，Python 的队列模块包含一个带有 get 方法的 Queue 类，该方法接受超时参数。这是手册中的部分:

Queue.get([block[, timeout]])
Remove and return an item from the queue. If optional args block is true and timeout is None (the default), block if necessary until an item is available. If timeout is a positive number, it blocks at most timeout seconds and raises the Empty exception if no item was available within that time. [...]

(强调我的)

请注意，它可能会引发 Empty 异常即使它还没有达到超时。事实上，我在 Ubuntu(但不是 Windows)上看到了这种行为。它只是提前了一点，并且对我的代码产生了轻微的影响 - 不过我可以围绕它进行编码。

大多数阻塞超时采用最小 超时，这在非实时操作系统(包括 Windows 和 Linux)上有意义。无法保证操作系统会在任何给定的截止日期前切换到您的进程或线程。

但是，这需要最大 超时。谁能解释一下这个设计决策的意义所在？

Answer 1

我认为您误解了文档。这并不是说它可能会在少于 timeout 秒后引发 Empty 异常，而是说它最多会阻塞 timeout 秒。如果它能满足 get 的要求，它可能会阻塞不到那个时间。

我知道您是说您看到它提早引发了 Empty，但老实说，这听起来像是一个错误，或者您依赖的准确性高于系统所能提供的准确性。 (似乎确实要遵守规范的确切措辞，实现应该将 timeout down 舍入到其计时器的分辨率，而不是像您希望的那样向上.)