| msg55044 - (view) |
Author: David Fraser (davidfraser) |
Date: 2007-03-05 13:33 |
| Currently the wait method on threading.Event always returns None, even if a timeout is given and the event is not set. This means that there is no way to determine whether the wait method returned because the event was set, or because the timeout period expired, without querying the event status again: x.wait(3) if x.isSet(): # do stuff Note that in the above case, the event could be cleared between the return from x.wait and the execution of x.isSet (in another thread), and so this would operate as though x.wait had just timed out It would be great to be able to do: if x.wait(3): # do stuff This should also not affect any existing code as it shouldn't be relying on the return value from x.wait anyway |
|
|
| msg66317 - (view) |
Author: Tim Lesher (tlesher) * |
Date: 2008-05-06 16:28 |
| This one-line change to threading.py makes Event.wait() return isSet(). Also includes the corresponding update to documentation in threading.rst. |
|
|
| msg66324 - (view) |
Author: Georg Brandl (georg.brandl) *  |
Date: 2008-05-06 17:22 |
| Tim, you said this was a bad idea for conditions in #1175933 - is the same true for Events? |
|
|
| msg71566 - (view) |
Author: Adam Milner (carmiac) |
Date: 2008-08-20 18:44 |
| I would like to add my support for this change. As David described, it is often useful to know why the x.wait() has returned, not just that it has. |
|
|
| msg72697 - (view) |
Author: Antoine Pitrou (pitrou) * |
Date: 2008-09-06 21:16 |
| I agree this would be a worthwhile addition too. Unfortunately given the current schedule this will probably have to wait for 2.7/3.1. |
|
|
| msg83556 - (view) |
Author: Antoine Pitrou (pitrou) * |
Date: 2009-03-14 01:09 |
| A test should be added to the patch, and then I think it could go in. |
|
|
| msg84546 - (view) |
Author: Tim Lesher (tlesher) * |
Date: 2009-03-30 14:07 |
| Thanks, Antoine. I will re-check the patch against trunk and add tests this week. |
|
|
| msg84569 - (view) |
Author: Guido van Rossum (gvanrossum) * |
Date: 2009-03-30 15:53 |
| Looking at this, I think this change is fine. The _Event class itself holds the condition that it's checking for, and the is_set() method doesn't acquire the lock, so there's no reason to prefer e.wait() if e.is_set(): GOT_IT() over if e.wait(): GOT_IT() IOW Tim's reasoning in #1175933 for rejecting a similar change to _Condition.wait() doesn't apply here. I think we can go ahead without waiting for Tim to confirm this. |
|
|
| msg84895 - (view) |
Author: Georg Brandl (georg.brandl) * |
Date: 2009-03-31 20:41 |
| Added a pony test and committed in r70883. |
|
|