-
Notifications
You must be signed in to change notification settings - Fork 237
Clean up LSP message tests #1700
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
Conversation
6891eb5
to
4184362
Compare
{ | ||
throw new Exception("Launch response was null."); | ||
} | ||
|
||
// This will check to see if we received the Initialized event from the server. | ||
await Task.Run( | ||
async () => await started.Task.ConfigureAwait(false), | ||
new CancellationTokenSource(2000).Token).ConfigureAwait(false); | ||
async () => await started.Task.ConfigureAwait(true), |
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.
since you're changing the behavior of the ConfigureAwait consider a comment to explain why the advice of https://docs.microsoft.com/en-us/dotnet/api/system.threading.tasks.task.configureawait?view=net-6.0#remarks isn't applicable.
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! Truly what I need to document is like in a developer's guide for PSES. Essentially, at the library level (any PSES code itself) we must disable the continue on captured context (i.e. false
) otherwise we deadlock when users import things like System.Windows.Forms
that start their own thread context. The library has to be setup to not care which it's on and so continue executing. At the "app" level (e.g. tests) we actually want it set to true
(also the default, but I setup a compiler rule to enforce that .ConfigureAwait
be called) because xUnit introduces its own thread context, and we run into deadlocks with tests because the test code (like UI/app code) needs to only continuing executing where it left off, otherwise it can cause the test to end up on the PSES pipeline thread.
So my rule for the codebase (which is documented in a couple places, but you're right it needs to be either in more or at a higher level) is: ConfigureAwait(false)
in PSES code, ConfigureAwait(true)
in test code. The latter won't always break things, and our initial run through when I enabled that compiler rule was to set everything to false
, hence they're all false
right now but as I'm cleaning up tests I'm fixing it. I should do a single PR fixing all the test code.
PwshExe = PsesStdioProcess.PwshExe; | ||
} | ||
|
||
public void Dispose() | ||
{ | ||
Diagnostics.Clear(); | ||
TelemetryEvents.Clear(); | ||
GC.SuppressFinalize(this); |
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.
Should this ever run on a finalizer thread? Is there a class destructor to finalize? Just wondering if this is needed.
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 had a long conversation with Dongbo to learn all about this and while this doesn't cause a bug, the compiler barfs a warning about it, and this is the "correct" fix. If this were product code it would be more important, but I'm working to just get us to a zero-warning codebase. Slowly, but surely.
Just applying automatic cleanups.