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 tim.peters
Recipients Tamas.K, bkabrda, csernazs, grahamd, jcea, koobs, ncoghlan, neologix, pitrou, python-dev, tim.peters
Date 2013-09-08.18:16:22
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
Without _stopped, join() can simply wait to acquire _tstate_lock (with or without a timeout, and skipping this if _tstate_lock is already None).  Etc ;-)  Of course details matter, but it's easy.  I did it once, but the tests joining the main thread failed and I put the code on hold.  I'll dust it off when the buildbots are all happy with the current changes.

> (also, why is the current Event implementation based
> on Condition?

We'd have to ask Guido ;-)  Best guess is that Condition supplied all the machinery to make Event.wait() work correctly, including waking all waiters up when the Event gets set.

> isn't an Event actually simpler than a Condition?)

Events are indeed simple :-)  There are many ways to implement them, but "ain't broke, don't fix" seems the right approach to me here.  In effect, if we get rid of _stopped, the code remaining will be much like an Event implementation built on the plain _tstate_lock lock.
Date User Action Args
2013-09-08 18:16:22tim.peterssetrecipients: + tim.peters, jcea, csernazs, ncoghlan, pitrou, grahamd, neologix, python-dev, bkabrda, koobs, Tamas.K
2013-09-08 18:16:22tim.peterssetmessageid: <>
2013-09-08 18:16:22tim.peterslinkissue18808 messages
2013-09-08 18:16:22tim.peterscreate