Changes by xiaobing jiang s7v7nisla...@gmail.com:
--
nosy: +s7v7nisla...@gmail.com
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15330
___
___
Chris Jerdonek chris.jerdo...@gmail.com added the comment:
Thanks for the info. A couple questions: what does won't break mean -- that
it won't throw an exception of a type that it wouldn't normally throw in a
single-threaded environment? And does this mean that not even deque.pop() is
Raymond Hettinger raymond.hettin...@gmail.com added the comment:
A couple questions: what does won't break mean
That means that its internal invariants always survive in a multi-threaded
environment.
that it won't throw an exception of a type that it
wouldn't normally throw in a
New submission from Chris Jerdonek chris.jerdo...@gmail.com:
It seems like it would be useful if collections.deque had a thread-safe method
that could rotate(1) and return the rotated value.
This would let deque to act as a thread-safe circular buffer (e.g. if serving
jobs to multiple threads
Changes by Raymond Hettinger raymond.hettin...@gmail.com:
--
assignee: - rhettinger
priority: normal - low
versions: +Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15330
___
Raymond Hettinger raymond.hettin...@gmail.com added the comment:
By thread-safe you mean that the operation should be atomic?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15330
___
Chris Jerdonek chris.jerdo...@gmail.com added the comment:
Yes, atomic. I was under the impression that the existing deque.rotate() is
atomic, in which case deque.rotate(1) almost provides what I'm suggesting
(lacking only the return value).
--
___
Raymond Hettinger raymond.hettin...@gmail.com added the comment:
We make almost no guarantees about atomicity. If something in CPython happens
to be atomic, it is not guaranteed to hold in other implementations. The
recommendation is to use locks anywhere you need a critical section of
