Fix two race conditions around pseudo window visibility #13832
Conversation
lhecker
added
Product-Conpty
|
@msftbot make sure @zadjii-msft signs off |
ghost
added
the
AutoMerge
|
Hello @DHowett! 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". |
|
I think this will primarily hit when there is (1) a lot of VT output and (2) an application calls Thoughts? |
ghost
merged commit 
|
@zadjii-msft should this be part of 1.15? |
|
@DHowett almost definitely |
This commit fixes two race conditions: * `SetPseudoWindowCallback` set the `_pseudoWindowMessageCallback` callback after the Win32 message thread was already spawned. This issue was fixed by instead using the `ServiceLocator` to get a hold of the global `VtIo` instance which is created statically. * `XtermEngine::SetWindowVisibility` was called without holding the console lock. This issue was fixed by simply acquiring it first. Closes MSFT:40913882 ## Validation Steps Performed * Add `IsConsoleLocked()` assertion in `VtEngine::_Write` * Run Windows Terminal * No assertion failures ✅ (cherry picked from commit 4f3afee) Service-Card-Id: 85487461 Service-Version: 1.15
|
🎉 Handy links: |
|
🎉 Handy links: |
This commit fixes two race conditions:
SetPseudoWindowCallbackset the_pseudoWindowMessageCallbackcallback after the Win32 message thread was already spawned.
This issue was fixed by instead using the
ServiceLocatorto geta hold of the global
VtIoinstance which is created statically.XtermEngine::SetWindowVisibilitywas called without holding theconsole lock. This issue was fixed by simply acquiring it first.
Closes MSFT:40913882
Validation Steps Performed
IsConsoleLocked()assertion inVtEngine::_Write