Documentation for Event.wait return value is either wrong or incomplete #57711
Description
| BPO | 13502 |
|---|---|
| Nosy | @tim-one, @pitrou, @bitdancer |
| 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 = None
closed_at = <Date 2012-01-07.19:40:56.442>
created_at = <Date 2011-11-29.20:45:15.541>
labels = ['type-bug', 'library']
title = 'Documentation for Event.wait return value is either wrong or incomplete'
updated_at = <Date 2012-01-07.19:40:56.441>
user = 'https://github.com/bitdancer'bugs.python.org fields:
activity = <Date 2012-01-07.19:40:56.441>
actor = 'neologix'
assignee = 'docs@python'
closed = True
closed_date = <Date 2012-01-07.19:40:56.442>
closer = 'neologix'
components = ['Library (Lib)']
creation = <Date 2011-11-29.20:45:15.541>
creator = 'r.david.murray'
dependencies = []
files = ['23866', '23897']
hgrepos = []
issue_num = 13502
keywords = ['patch']
message_count = 12.0
messages = ['148604', '148606', '148608', '148610', '148641', '148984', '149018', '149019', '149130', '149150', '149160', '150809']
nosy_count = 6.0
nosy_names = ['tim.peters', 'pitrou', 'r.david.murray', 'neologix', 'docs@python', 'python-dev']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue13502'
versions = ['Python 2.7', 'Python 3.2', 'Python 3.3']
Activity
bitdancer commentedon Nov 29, 2011
The documentation for Event.wait says:
This method returns the internal flag on exit, so it will always return True except if a timeout is given and the operation times out.
In fact, however, if the thread that sets the flag immediately clears it, wait will return False. Antoine looking at the code says that this appears to be intentional, and that would make sense since originally wait returned no value.
My use case is one thread waiting on another to complete a work loop. Normally the worker thread goes to sleep after clearing the flag, but sometimes it immediately starts a new work loop. In either case I want the monitoring loop to take an action when the work loop completes, and raise an error if the wait times out. It looked to me like Event.wait would work in the scenario.
bitdancer commentedon Nov 29, 2011
Thinking about it, if the flag's state if the wait does not expire is not guaranteed to be True, then what I really need is some way to know, when the wait call completes, whether or not it terminated because of a timeout or not. I can always query the value of the flag separately if its value can in any case be changed by another thread.
I am perhaps using the wrong tool, I'll have to look at the docs further.
pitrou commentedon Nov 29, 2011
Ok, so digging a bit, the feature dates back to bpo-1674032.
Interestingly, the OP in that issue had already envisioned that race condition and had precisely proposed the feature to avoid it: “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”.
So I'm changing my mind and saying it seems desireable to return True if the wait succeeded before the timeout's end, even though the flag may have been reset in the meantime.
In 3.2, Condition.wait also returns a boolean, meaning the check in Event.wait can be atomic.
bitdancer commentedon Nov 29, 2011
Changing the title and component to reflect Antoine's new understanding :)
[-]Documentation for Event.wait return value is either wrong or incomplete[/-][+]Event.wait sometimes returns False even when no timeout has occurred[/+]neologix commentedon Nov 30, 2011
Agreed. What matters is that the event has been signaled, not that
it's currently signaled.
[-]Event.wait sometimes returns False even when no timeout has occurred[/-][+]Documentation for Event.wait return value is either wrong or incomplete[/+]neologix commentedon Dec 7, 2011
Here's a patch.
bitdancer commentedon Dec 8, 2011
On Wed, 07 Dec 2011 18:45:27 +0000, report@bugs.python.org wrote:
This seems to imply that if the current thread previously set the event,
the wait will return False, which is contradicted by the 'so' statement
(which appears to be correct).
--David
neologix commentedon Dec 8, 2011
You're probably referring to the "another thread" part...
A suggestion ? I see you're a native speaker :-)
bitdancer commentedon Dec 9, 2011
"set to True, either before the wait call or after the wait starts"
neologix commentedon Dec 10, 2011
Thanks, here's a patch updated accordingly.
bitdancer commentedon Dec 10, 2011
LGTM.
python-dev commentedon Jan 7, 2012
New changeset eb39d862a250 by Charles-François Natali in branch '3.2':
Issue bpo-13502: threading: Fix a race condition in Event.wait() that made it
http://hg.python.org/cpython/rev/eb39d862a250
New changeset 0fe63bb20e74 by Charles-François Natali in branch 'default':
Issue bpo-13502: threading: Fix a race condition in Event.wait() that made it
http://hg.python.org/cpython/rev/0fe63bb20e74