Kristján Valur Jónsson <krist...@ccpgames.com> added the comment: Okay, here is a new submission. I've redesigned it to be more reminiscent of the Java version, by allowing the barrier to have a "Broken" state and raising a BrokenBarrierError. I've also redesigned the mechanism from a simple perpetually increasing index of "entered" and "released" into a proper two-state machine which is either "filling" or "draining".
There is also a rather comprehensive set of tests. What is missing is documentation, somethign I shall add if this gets a positive response. Note how, in the tests, I sometimes create a "barrier2" object to facilitate external synchronization. This demonstrates the simplicity of using this primitive. Another note: In order to implement "timeout" behaviour, I changed Condition.wait() to return True in case it returns due to a timeout occurring. I folded this into this patch, but if such a change is not accepted, or we want it separately, then I'll have to remove the timeout functionality from the Barrier. I don't want to have complicated logic in there to measure time. Also, I do think that locking primitives that time out should be able to provide an indication to that fact to their callers, so condition.wait() really should do that. ---------- Added file: http://bugs.python.org/file19379/barrier3.patch _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue8777> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
