-
Notifications
You must be signed in to change notification settings - Fork 8.4k
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
Call UpdatePatternLocations from a background thread #13758
Conversation
UpdatePatternLocationsInterval, | ||
[weakThis = get_weak()]() { | ||
if (auto core{ weakThis.get() }; !core->_IsClosing()) | ||
if (auto core{ weakThis.get() }) |
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.
How can we be sure now that the control isn't tearing down?
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.
We simply can't. After all, _IsClosing
isn't a mutex which would prevent the main thread from closing under us while we're running on the background thread.
Thankfully, Terminal::_InvalidatePatternTree
doesn't seem to depend on any UI state.
Thinking about it, this is actually a good change in general. Reading the |
@msftbot merge this in 15 minutes |
Hello @lhecker! Because you've given me some instructions on how to help merge this pull request, I'll be modifying my merge approach. Here's how I understand your requirements for merging this pull request:
If this doesn't seem right to you, you can tell me to cancel these instructions and use the auto-merge policy that has been configured for this repository. Try telling me "forget everything I just told you". |
🎉 Handy links: |
🎉 Handy links: |
We have a number of theories why microsoft#12607 is happening, one of which is that some GPU drivers somehow rely on Win32 messages or similar which we process on the main thread. If we then try to acquire the console lock on the main thread, while the GPU-driver thread itself is holding that lock, we've got ourselves a deadlock. This PR makes this less likely by running the repeat offender `UpdatePatternLocations` on a background thread instead. We have a number of other locations which acquire the console lock on the main thread and a thorough bug fix must be done in a different way. ## Validation Steps Performed * After pasting an URL it gets underlined on hover ✅ (cherry picked from commit 23e4d31) Service-Card-Id: 85033019 Service-Version: 1.15
We have a number of theories why microsoft#12607 is happening, one of which is that some GPU drivers somehow rely on Win32 messages or similar which we process on the main thread. If we then try to acquire the console lock on the main thread, while the GPU-driver thread itself is holding that lock, we've got ourselves a deadlock. This PR makes this less likely by running the repeat offender `UpdatePatternLocations` on a background thread instead. We have a number of other locations which acquire the console lock on the main thread and a thorough bug fix must be done in a different way. * After pasting an URL it gets underlined on hover ✅ (cherry picked from commit 23e4d31) Service-Card-Id: 85033018 Service-Version: 1.14
We have a number of theories why #12607 is happening, one of which is that
some GPU drivers somehow rely on Win32 messages or similar which we process
on the main thread. If we then try to acquire the console lock on the main
thread, while the GPU-driver thread itself is holding that lock, we've got
ourselves a deadlock. This PR makes this less likely by running the repeat
offender
UpdatePatternLocations
on a background thread instead.We have a number of other locations which acquire the console lock on the
main thread and a thorough bug fix must be done in a different way.
Validation Steps Performed