-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
[DefApp] Move from Monarch multi instance servers to Peasant single instance servers #10823
Conversation
…w the inbound connection onto the UI thread so it doesn't have a hissy fit.
…at makes things mad.
…tab failed to be created from defterm and can tell com that it shit the bed
…rformed on a UI thread
LOVE IT. IT MAKES SO MUCH SENSE |
@msftbot make sure @miniksa signs off on this |
Hello @zadjii-msft! 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". |
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.
Hokay so lemme get this straight:
- COM creates a
wt -embedding
process to try and host the incoming connection - that wt automatically tosses the commandline to the Monarch to have it deal with it.
- The monarch will then either
- Toss the commandline
wt -embedding
to the appropriate peasant, who then- starts the COM server
- accepts the connection
- stops the server
- opens the tab
- Or the monarch decides that this connection should be a new peasant (a new window)
- the new window opens
- starts the server, accepts the connection, ... opens the tab
all based on what we already had.
That's fricken amazing.
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.
|
||
_SummonWindowRequestedHandlers(*this, nullptr); | ||
|
||
std::unique_lock<std::mutex> lock{ mtx }; |
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.
Something is up here and I'm not certain what it is.
It worries me that you covered one definition of lock (since the lambda captured everything) with another more local definition of the same thing.
The inside of this lambda isn't even using the lock. Is it? Am I missing an implicit piece of the construction here?
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.
I should probably change the name of the lock inside of the lambda, that's a good point.
As for whether the inside of the lambda is using the lock, we should technically be acquiring the lock before modifying finalVal
since that's the shared resource right?
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.
I need an adult to answer that. I just copied this pattern from somewhere else. @lhecker halp.
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.
(This is where I stole the idea from:
terminal/src/cascadia/TerminalSettingsModel/CascadiaSettingsSerialization.cpp
Lines 57 to 78 in d57fb84
template<typename TTask> | |
static auto _extractValueFromTaskWithoutMainThreadAwait(TTask&& task) -> decltype(task.get()) | |
{ | |
using TVal = decltype(task.get()); | |
std::optional<TVal> finalVal{}; | |
std::condition_variable cv; | |
std::mutex mtx; | |
auto waitOnBackground = [&]() -> winrt::fire_and_forget { | |
co_await winrt::resume_background(); | |
auto v{ co_await task }; | |
std::unique_lock<std::mutex> lock{ mtx }; | |
finalVal.emplace(std::move(v)); | |
cv.notify_all(); | |
}; | |
std::unique_lock<std::mutex> lock{ mtx }; | |
waitOnBackground(); | |
cv.wait(lock, [&]() { return finalVal.has_value(); }); | |
return *finalVal; | |
} |
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.
You can use til::latch
for this now. Less overhead & easier to use. 🙂
- You need to import it yourself as
<til/latch.h>
(just like a stdlib header - no need to put it intopch.h
) - Instantiate it as
til::latch latch(1);
- Replace the mutex/condition_variable code inside the lambda with
lath.count_down()
- Replace the mutex/condition_variable code outside the lambda with
latch.wait()
- Just make sure to write the data before counting down and only read from it after wait() has returned.
Hello @zadjii-msft! Because this pull request has the p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (
|
…nstance servers (#10823) - Monarch no longer sets itself up as a `CTerminalHandoff` multi instance server by default - In fact, `CTerminalHandoff` will only ever be a single instance server - When COM needs a `CTerminalHandoff`, it launches `wt.exe -embedding`, which gets picked up by the Monarch and then gets handed off to itself/peasant depending on user settings. - Peasant now recognizes the `-embedding` commandline and will start a `CTerminalHandoff` single instance listener, and receives the connection into a new tab. Closes #10358
🎉 Handy links: |
🎉 Handy links: |
CTerminalHandoff
multi instance server by defaultCTerminalHandoff
will only ever be a single instance serverCTerminalHandoff
, it launcheswt.exe -embedding
, which gets picked up by the Monarch and then gets handed off to itself/peasant depending on user settings.-embedding
commandline and will start aCTerminalHandoff
single instance listener, and receives the connection into a new tab.Closes #10358, #9475