Roundup Robot devn...@psf.upfronthosting.co.za 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
Changes by Richard Oudkerk shibt...@gmail.com:
--
resolution: - fixed
stage: - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14059
___
Richard Oudkerk shibt...@gmail.com 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:
Richard Oudkerk shibt...@gmail.com 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
Antoine Pitrou pit...@free.fr 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
Antoine Pitrou pit...@free.fr added the comment:
RawValue uses ctypes, right? That's problematic for platforms which don't
support ctypes.
--
nosy: +pitrou
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14059
Charles-François Natali neolo...@free.fr 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
Changes by Antoine Pitrou pit...@free.fr:
--
dependencies: +multiprocessing.Condition.wait_for missing
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14059
___
sbt shibt...@gmail.com added the comment:
Patch which subclasses threading.Barrier.
--
keywords: +patch
Added file: http://bugs.python.org/file24614/mp_barrier.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14059
sbt shibt...@gmail.com added the comment:
Forgot to mention, mp_barrier.patch needs to be applied on top of
cond_wait_for.patch for Issue14087.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14059
sbt shibt...@gmail.com 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
sbt shibt...@gmail.com 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
sbt shibt...@gmail.com 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:
Charles-François Natali neolo...@free.fr 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
New submission from Matt Joiner anacro...@gmail.com:
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:
15 matches
Mail list logo
