-
Notifications
You must be signed in to change notification settings - Fork 305
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sync ReadKeyProc thread with pipeline thread #3294
Sync ReadKeyProc thread with pipeline thread #3294
Conversation
The pipeline thread was returning before the ReadKeyProcThread had finished processing the dummy input. This was occuring somewhat frequently when ReadLine was invoked multiple times in a row creating a race condition. With these changes, the pipeline thread will wait for dummy input to be received, dequeue the key, and continue with normal cancellation logic.
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.
Super freaking interesting. Can we setup a call with @daxian-dbw and step through this? I think you've found the threads racing, but damn, this is interesting.
Yeah definitely ❤️ |
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.
@SeeminglyScience Good work narrowing down the cause!
There may still be a race condition with this change. timeout case won't affect this change. Looking.
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.
LGTM with a minor comment.
Also tested and verified, and this resolves the problem. We've (well, @SeeminglyScience really) narrowed down the "extra prompt" issue as well, and while related to what we've been debugging, the cause is separate (our |
@@ -877,7 +861,7 @@ private void DelayedOneTimeInitialize() | |||
_readKeyWaitHandle = new AutoResetEvent(false); | |||
_keyReadWaitHandle = new AutoResetEvent(false); | |||
_closingWaitHandle = new ManualResetEvent(false); | |||
_requestKeyWaitHandles = new WaitHandle[] {_keyReadWaitHandle, _closingWaitHandle, null}; |
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.
Ah ha, the questions I had earlier but hadn't written yet are now irrelevant. Yay!
Would it make sense to use |
Oooo another good catch, yeah I think that would work fine now since |
We can now use CancellationToken.None instead of creating a dummy cancellation token because we use `CancellationToken.IsCancellationRequested`.
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.
LGTM!
Woo-hoo! |
🎉 |
PR Summary
Fix #3292
The pipeline thread was returning before the
ReadKeyProc
thread had finished processing the dummy input. This was occurring somewhat frequently whenReadLine
was invoked multiple times in a row, surfacing a race condition.With these changes, the pipeline thread will wait for dummy input to be received, dequeue the key, and continue with normal cancellation logic.
PR Checklist
Microsoft Reviewers: Open in CodeFlow