This repository has been archived by the owner on Sep 8, 2024. It is now read-only.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Improve the speed of waiting for dialogs helper function #2946
Improve the speed of waiting for dialogs helper function #2946
Changes from all commits
2a9f63c
4d7ed0f
105a5b4
fbb1d06
6fd97b4
8f41d17
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can
bus.new_message_available.wait(0.5)
be used to make it a bit more snappy?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In my testing, using the message_available event caused a very tight loop because there are so many message bus messages being emitted. Instead of looping ten times, as this code does, it looped hundreds of times. I would like to avoid these types of waits completely and just use message bus events with timeouts.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not seeing the issue with the tight loop, this waits for messages as soon as messages arrive we want to evaluate them. But you are right in this case an event driven approach would be much tidier. Can we change the implementation to something similar to:
Where historical messages would be just check the current stack of received messages for matches to handle the case where the desired 'speak' message arrives between the when and then steps.