Author tim.peters
Recipients jmoy, rhettinger, serhiy.storchaka, tim.peters
Date 2017-02-08.05:04:57
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1486530297.71.0.57515923468.issue29449@psf.upfronthosting.co.za>
In-reply-to
Content
I can't judge a use case for a thread gimmick in the absence of wholly specified examples.  There are too many possible subtleties.  Indeed, if I'd do anything with Event.clear() it would be to remove it - I've seen too much code that suffers subtle race bugs when trying to reset an event.  The one thing it's clearly good for is announcing a one-time global state change, for which it's sufficient, efficient, clear, and hard to get wrong.

Can you use a Barrier instead?  The Barrier design allows reuse with no special care, Barrier.wait() already returns a little integer unique to each thread, and the Barrier constructor even allows a function to be passed in to be executed by (exactly) one of the threads when the Barrier is complete.
History
Date User Action Args
2017-02-08 05:04:57tim.peterssetrecipients: + tim.peters, rhettinger, jmoy, serhiy.storchaka
2017-02-08 05:04:57tim.peterssetmessageid: <1486530297.71.0.57515923468.issue29449@psf.upfronthosting.co.za>
2017-02-08 05:04:57tim.peterslinkissue29449 messages
2017-02-08 05:04:57tim.peterscreate