[issue14059] Implement multiprocessing.Barrier

2012-06-15 Thread Richard Oudkerk
Changes by Richard Oudkerk : -- resolution: -> fixed stage: -> committed/rejected status: open -> closed ___ Python tracker ___ ___

[issue14059] Implement multiprocessing.Barrier

2012-06-15 Thread Roundup Robot
Roundup Robot added the comment: New changeset 2d2f206d040e by Richard Oudkerk in branch 'default': Issue #14059: Implement multiprocessing.Barrier http://hg.python.org/cpython/rev/2d2f206d040e -- nosy: +python-dev ___ Python tracker

[issue14059] Implement multiprocessing.Barrier

2012-06-05 Thread Richard Oudkerk
Richard Oudkerk added the comment: The attached patch uses memoryview instead of ctypes. If the patch for Issue #14953 (reimplementing RawArray/RawValue in terms of memoryview) is applied, then it could be simplified a bit. -- Added file: http://bugs.python.org/file25835/mp_barrier.pa

[issue14059] Implement multiprocessing.Barrier

2012-05-26 Thread Antoine Pitrou
Antoine Pitrou added the comment: > > RawValue uses ctypes, right? That's problematic for platforms which don't > > support ctypes. > > Are there many posix systems (we care about) where ctypes doesn't > work? It depends what you call "caring about" :-) But proprietary Unix C compilers genera

[issue14059] Implement multiprocessing.Barrier

2012-05-26 Thread Richard Oudkerk
Richard Oudkerk added the comment: > RawValue uses ctypes, right? That's problematic for platforms which don't > support ctypes. Are there many posix systems (we care about) where ctypes doesn't work? It would be fairly easy to use memoryview instead of ctypes. (In fact Value/RawValue could

[issue14059] Implement multiprocessing.Barrier

2012-04-27 Thread Antoine Pitrou
Antoine Pitrou added the comment: RawValue uses ctypes, right? That's problematic for platforms which don't support ctypes. -- nosy: +pitrou ___ Python tracker ___

[issue14059] Implement multiprocessing.Barrier

2012-04-25 Thread Charles-François Natali
Charles-François Natali added the comment: The patch looks good. However, I've had two failures while testing it: - a BrokenBarrierError on test_default_timeout: I see you've already increased the timeout from the original threading code, but you can probably double it (we have some slow build

[issue14059] Implement multiprocessing.Barrier

2012-03-31 Thread Antoine Pitrou
Changes by Antoine Pitrou : -- dependencies: +multiprocessing.Condition.wait_for missing ___ Python tracker ___ ___ Python-bugs-list m

[issue14059] Implement multiprocessing.Barrier

2012-02-23 Thread sbt
sbt added the comment: Forgot to mention, mp_barrier.patch needs to be applied on top of cond_wait_for.patch for Issue14087. -- ___ Python tracker ___ _

[issue14059] Implement multiprocessing.Barrier

2012-02-23 Thread sbt
sbt added the comment: Patch which subclasses threading.Barrier. -- keywords: +patch Added file: http://bugs.python.org/file24614/mp_barrier.patch ___ Python tracker ___ ___

[issue14059] Implement multiprocessing.Barrier

2012-02-22 Thread sbt
sbt added the comment: > Wouldn't it be simpler with a mp.Condition? Well, it is a fair bit shorter than the implementation in threading.py. But that is not a fair comparison because it does implement reset(). I was trying to avoid using shared memory/ctypes since multiprocessing.synchroniz

[issue14059] Implement multiprocessing.Barrier

2012-02-20 Thread Charles-François Natali
Charles-François Natali added the comment: > Here is an initial implementation. Wouldn't it be simpler with a mp.Condition? Otherwise, this should be added to Lib/multiprocesing.synchronize.py, and the tests to test_multiprocessing. -- nosy: +neologix ___

[issue14059] Implement multiprocessing.Barrier

2012-02-20 Thread sbt
sbt added the comment: barrier_tests.py contains minor modifications of the unit tests for threading.Barrier. (The two tests using reset() are commented out.) The implementation passes for me on Linux and Windows. -- Added file: http://bugs.python.org/file24580/barrier_tests.py _

[issue14059] Implement multiprocessing.Barrier

2012-02-20 Thread sbt
sbt added the comment: Here is an initial implementation. Differences from threading.Barrier: - I have not implemented reset(). - wait() returns 0 or -1. One thread returns 0, the remainder return -1. This is different to threading.Barrier where each of the N threads returns a unique in

[issue14059] Implement multiprocessing.Barrier

2012-02-19 Thread Matt Joiner
New submission from Matt Joiner : There is no Barrier in multiprocessing corresponding to threading.Barrier. -- components: Library (Lib) messages: 153744 nosy: anacrolix priority: normal severity: normal status: open title: Implement multiprocessing.Barrier type: enhancement versions: P