-
Notifications
You must be signed in to change notification settings - Fork 1.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
Take steps to avoid threadpool starvation #11275
Conversation
Related to #11160 |
/azp run |
Pull request contains merge conflicts. |
src/Build/BackEnd/Components/Communications/NodeProviderOutOfProcBase.cs
Show resolved
Hide resolved
src/Build/BackEnd/Components/Communications/NodeProviderOutOfProcBase.cs
Show resolved
Hide resolved
I've pushed some tweaks involving channels and setting up a drain thread in a slightly different manner - the old construct of |
6bd3585
to
56bee6b
Compare
I've removed my experimental changes for now. Let's aim to review & merge this, then return to it at a later date. |
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.
LGTM, I have couple of small comments.
I implemented the changes I suggested, @SimaTian please review again. |
Fixes #
Context
There are a handful of areas where threadpool threads are unnecessarily blocked by synchronous work, or there is additional contention that can be avoided. The most egregious instance is the synchronous read in BuferedReadStream
The outer call to BeginRead() ends up calling BufferedReadStream.Read() which synchronously blocks when _innerStream.Read() is called. This results in a substantial amount of block time for threadpool threads.
Changes Made
Testing
Notes