Repository navigation
Make threading.Event().wait(timeout=3) return isSet #44660
Description
| BPO | 1674032 |
|---|---|
| Nosy | @gvanrossum, @tim-one, @birkenfeld, @pitrou |
| Files |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = 'https://github.com/birkenfeld'
closed_at = <Date 2009-03-31.20:41:16.373>
created_at = <Date 2007-03-05.13:33:33.000>
labels = ['type-feature', 'library']
title = 'Make threading.Event().wait(timeout=3) return isSet'
updated_at = <Date 2009-03-31.20:41:16.372>
user = 'https://bugs.python.org/davidfraser'bugs.python.org fields:
activity = <Date 2009-03-31.20:41:16.372>
actor = 'georg.brandl'
assignee = 'georg.brandl'
closed = True
closed_date = <Date 2009-03-31.20:41:16.373>
closer = 'georg.brandl'
components = ['Library (Lib)']
creation = <Date 2007-03-05.13:33:33.000>
creator = 'davidfraser'
dependencies = []
files = ['10203']
hgrepos = []
issue_num = 1674032
keywords = ['patch']
message_count = 9.0
messages = ['55044', '66317', '66324', '71566', '72697', '83556', '84546', '84569', '84895']
nosy_count = 7.0
nosy_names = ['gvanrossum', 'tim.peters', 'georg.brandl', 'davidfraser', 'pitrou', 'tlesher', 'carmiac']
pr_nums = []
priority = 'normal'
resolution = 'accepted'
stage = None
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue1674032'
versions = ['Python 3.1', 'Python 2.7']
Activity
davidfraser commentedon Mar 5, 2007
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:
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:
This should also not affect any existing code as it shouldn't be relying on the return value from x.wait anyway
tlesher commentedon May 6, 2008
This one-line change to threading.py makes Event.wait() return isSet().
Also includes the corresponding update to documentation in threading.rst.
birkenfeld commentedon May 6, 2008
Tim, you said this was a bad idea for conditions in bpo-1175933 - is the
same true for Events?
carmiac commentedon Aug 20, 2008
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.
pitrou commentedon Sep 6, 2008
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.
pitrou commentedon Mar 14, 2009
A test should be added to the patch, and then I think it could go in.
tlesher commentedon Mar 30, 2009
Thanks, Antoine. I will re-check the patch against trunk and add tests
this week.
gvanrossum commentedon Mar 30, 2009
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
over
IOW Tim's reasoning in bpo-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.
birkenfeld commentedon Mar 31, 2009
Added a pony test and committed in r70883.