[issue15329] clarify which deque methods are thread-safe

Changes by xiaobing jiang : -- nosy: +s7v7nisla...@gmail.com ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: ht

[issue15329] clarify which deque methods are thread-safe

Changes by Raymond Hettinger : -- resolution: -> invalid status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing l

[issue15329] clarify which deque methods are thread-safe

Raymond Hettinger added the comment: > So, is deque a faster replacement for Queue.Queue or not? Yes, it is faster. The Queue module itself uses the deque internally. And the Queue is slowed down a bit through locks, function indirection, and additional features such as maxsize, join, and ta

[issue15329] clarify which deque methods are thread-safe

anatoly techtonik added the comment: So, is deque a faster replacement for Queue.Queue or not? -- nosy: +techtonik ___ Python tracker ___

[issue15329] clarify which deque methods are thread-safe

Chris Jerdonek added the comment: I created issue 15339 to document the multi-threading "facts of life" in Python (independent of any particular module or package, including this one), along the lines suggested by Raymond. -- ___ Python tracker

[issue15329] clarify which deque methods are thread-safe

Antoine Pitrou added the comment: > Classes written in C are necessarily thread-safe (they rely on the GIL) That's not really true. A single Py_DECREF() can release the GIL by way of executing a Python __del__ method (or a weakref callback, or even the tp_dealloc of a file object that happens

[issue15329] clarify which deque methods are thread-safe

Amaury Forgeot d'Arc added the comment: > Pypy tends to make fewer guarantees because it implements > more classes in pure python. This is not exactly true; in PyPy the _collection module was rewritten in RPython (which is translated to C) for this very reason: to make dequeue.append atomic

[issue15329] clarify which deque methods are thread-safe

Raymond Hettinger added the comment: I think you're over-reaching. We make almost no guarantees about atomicity. Having multiple implementations of Python makes that an even harder task. In general, critical sections need to be guarded with locks. If an object claims to be thread-safe,

[issue15329] clarify which deque methods are thread-safe

Chris Jerdonek added the comment: I think some of the information in the issue 15330 comments would be very helpful to add as well (what thread-safe means in Python, distinction between thread-safe and atomic, and which deque methods are thread-safe and/or atomic). If some of that information

[issue15329] clarify which deque methods are thread-safe

Changes by Raymond Hettinger : -- assignee: docs@python -> rhettinger ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubsc

[issue15329] clarify which deque methods are thread-safe

New submission from Chris Jerdonek : I think it would help to clarify which collections.deque methods are thread-safe: http://docs.python.org/dev/library/collections.html?highlight=deque#collections.deque Currently, the documentation says that "Deques support thread-safe, memory efficient app