This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author kristjan.jonsson
Recipients georg.brandl, giampaolo.rodola, jyasskin, kristjan.jonsson
Date 2010-10-27.01:06:18
SpamBayes Score 9.869655e-11
Marked as misclassified No
Message-id <1288141584.59.0.324890152682.issue8777@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2010-10-27 01:06:24kristjan.jonssonsetrecipients: + kristjan.jonsson, georg.brandl, giampaolo.rodola, jyasskin
2010-10-27 01:06:24kristjan.jonssonsetmessageid: <1288141584.59.0.324890152682.issue8777@psf.upfronthosting.co.za>
2010-10-27 01:06:22kristjan.jonssonlinkissue8777 messages
2010-10-27 01:06:22kristjan.jonssoncreate