Fix a thread pool test#67399
Conversation
- The test verifies that cooperative blocking in `Task.Wait()` causes threads to be injected quickly enough that it does not time out due to starvation - Cooperative blocking checks memory usage and limit, and beyond a threshold of memory usage does not inject threads quickly - Following a build of the runtime repo, there are several `dotnet` processes that remain running, each using several 100s of MBs and one using ~1.3 GB of memory - If the test runs soon after the build, before those processes exit, it's possible for the reported memory usage to be high enough that the test would fail - Added a config var to ignore memory usage and used it in the test Fixes #66852
|
Tagging subscribers to this area: @mangod9 Issue Details
Fixes #66852
|
| public static readonly bool IsCooperativeBlockingEnabled = | ||
| AppContextConfigHelper.GetBooleanConfig("System.Threading.ThreadPool.Blocking.CooperativeBlocking", true); | ||
| public static readonly bool IgnoreMemoryUsage = | ||
| AppContextConfigHelper.GetBooleanConfig("System.Threading.ThreadPool.Blocking.IgnoreMemoryUsage", false); |
There was a problem hiding this comment.
Do we expect this to be set by actual consumers, or we're exposing this purely for our own internal testing purposes?
There was a problem hiding this comment.
There are other knobs that allow removing the limits for thread injection, so I figured this could be a reasonable knob to be able to set, especially on machines with relatively lower memory and where the heuristic may limit thread injection when the starvation may be a larger issue.
|
Do I understand correctly that |
|
Yes, I had intended |
mangod9
left a comment
mangod9
left a comment
There was a problem hiding this comment.
Assume we would add some documentation about this new setting?
|
Yep I'll add it in a separate PR, thanks! |
ghost
locked as resolved and limited conversation to collaborators
4 participants
Task.Wait()causes threads to be injected quickly enough that it does not time out due to starvationdotnetprocesses that remain running, each using several 100s of MBs and one using ~1.3 GB of memoryFixes #66852