Message197306
| 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 |
<1378664182.39.0.963065546725.issue18808@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
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. |
|
History
|
|---|
| Date |
User |
Action |
Args |
| 2013年09月08日 18:16:22 | tim.peters | set | recipients:
+ tim.peters, jcea, csernazs, ncoghlan, pitrou, grahamd, neologix, python-dev, bkabrda, koobs, Tamas.K |
| 2013年09月08日 18:16:22 | tim.peters | set | messageid: <1378664182.39.0.963065546725.issue18808@psf.upfronthosting.co.za> |
| 2013年09月08日 18:16:22 | tim.peters | link | issue18808 messages |
| 2013年09月08日 18:16:22 | tim.peters | create |
|