如果 `queue.Queue` 已经存在并且是线程安全的,为什么还有 `gevent.queue.Queue`?

Why is there `gevent.queue.Queue` if `queue.Queue` already exists and is thread-safe?

有一个问题 询问 gevent.queue.Queue 的必要性,因为没有并行性,只有与 gevent 的并发性。正确地,答案解释:

[...] you might want to ensure that a series of statements execute atomically [...]

所以每个方法都应该是原子的,这解释了为什么我们需要一个队列对象而不是一个 "regular" 列表,例如。然而,根据 Python 文档 https://docs.python.org/3/library/queue.html 一个 queue.Queue 对象已经具有这些安全特性:

It is especially useful in threaded programming when information must be exchanged safely between multiple threads. The Queue class in this module implements all the required locking semantics.

那么为什么 gevent.queue.Queue 已经存在 queue.Queue 呢?是否需要更多安全功能或性能问题?

在 GitHub 个问题之一的 this comment 中有这个问题的答案:

gevent's Queue is directly implemented in terms of gevent primitives, rather than going through the abstraction of the monkey-patched threading libraries like the standard library Queue must do, and gevent's Queue can take advantage of the fact that certain operations cannot be interrupted by other greenlets. This lets it have reduced overhead and better performance.

gevent's Queue is compatible with gevent and greenlets even if monkey-patching isn't used, whereas the standard library Queue isn't and requires monkey-patching. Not everyone like to monkey-patch.

gevent's Queue also has a slightly richer interface, for example it can be iterated.