Message153958
> 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.synchronize does not currently use them. However, I think it would be better (and much simpler) to just subclass threading.Barrier, making self._state and self._counter properties which delegate to RawValue objects. That gets rid of the differences in behaviour. I have this working, although I had to monkey patch multiprocessing.Condition to add a wait_for() method. See Issue 14087.
> Otherwise, this should be added to Lib/multiprocesing.synchronize.py,
> and the tests to test_multiprocessing.
I will provide a patch later. |
|
Date |
User |
Action |
Args |
2012-02-22 15:28:21 | sbt | set | recipients:
+ sbt, anacrolix, neologix |
2012-02-22 15:28:21 | sbt | set | messageid: <1329924501.6.0.72507536452.issue14059@psf.upfronthosting.co.za> |
2012-02-22 15:28:21 | sbt | link | issue14059 messages |
2012-02-22 15:28:20 | sbt | create | |
|