Put unhandled responses back on the queue #440
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Author
|
I think this should fix #349 |
In a multithreaded environment (such as having a separate thread to wait for notifications), it's possible that the response for one event (such as the completion of a write) may be consumed by another thread (such as one that's just waiting for notifications). If the write response is never delivered to the correct thread, it will block - and if there are no timeouts, it will deadlock. This approach simply makes the assumption that if an unhandled event shows up, it was probably intended for another thread - simply putting it back on the queue will allow that other thread to have a go at parsing it. In the event of a genuinely unexpected message this will result in a lot of busy work and the event never being cleared, which isn't ideal. I'm not sure if there's a more reasonable approach to this.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
In a multithreaded environment (such as having a separate thread to wait
for notifications), it's possible that the response for one event (such
as the completion of a write) may be consumed by another thread (such as
one that's just waiting for notifications). If the write response is never
delivered to the correct thread, it will block - and if there are no
timeouts, it will deadlock.
This approach simply makes the assumption that if an unhandled event shows
up, it was probably intended for another thread - simply putting it back
on the queue will allow that other thread to have a go at parsing it. In
the event of a genuinely unexpected message this will result in a lot of
busy work and the event never being cleared, which isn't ideal. I'm not
sure if there's a more reasonable approach to this.