Fixing async apis and reducing the number of threads we block#15289
Fixing async apis and reducing the number of threads we block#15289nohwnd wants to merge 2 commits intomicrosoft:mainfrom
Conversation
| // todo: report standard error on timeout | ||
| await Task.WhenAny(_communicationManager.AcceptClientAsync(), Task.Delay(clientConnectionTimeout)).ConfigureAwait(false); | ||
|
|
||
| _handShakeSuccessful = await HandShakeWithVsTestConsoleAsync().ConfigureAwait(false); |
There was a problem hiding this comment.
This code is completely broken. We are waiting for console to connect here, but we did not return from this method, so the port was never given to the code that starts the console. So there is no process that would ever call us back.
| "DOTNET_ThreadPool_ForceMinWorkerThreads": "1", | ||
| "DOTNET_ThreadPool_ForceMaxWorkerThreads": "1" |
There was a problem hiding this comment.
forces us to single threadpool thread to make sure we don't get blocked when running, and don't block threadpool threads.
There was a problem hiding this comment.
forces us to single threadpool thread to make sure we don't get blocked when running, and don't block threadpool threads.
Thread pool is hard to focus
There was a problem hiding this comment.
This caused issue in some other place where we observed complete blockage of vstest because the process set those variables. This is playgroud project that was trying to repro it. I think the problem of our code is well understood now, the seemingly async apis for process observation are sync and block threads. Which pushes thread pool to grow, and thread pool grows slowly. New apis are coming in net11, and fixes for the current apis as well.
|
Not fixing stage pull |
2 participants
e.g. if we do discoveryAsync, and then do RunTests (sync), we get stuck.