search

dotnet / runtime

.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.
https://docs.microsoft.com/dotnet/core/
MIT License
14.95k stars 4.65k forks source link

consider pulling long running threatpool threads from the pool #105165

Open danmoseley opened 1 month ago

danmoseley commented 1 month ago

Work scheduled with TaskCreationOptions.LongRunning currently always creates a new thread. If the threadpool is sufficiently idle then it might be worthwhile to grab an idle threadpool thread to use instead - and kick off creating a replacement one to put in the threadpool.

This assumes that there are enough of these work items to make it worthwhile, and that thread startup is large enough to be relevant to them. That may well not be the case. Also, this could potentially be a deoptimization if it delays short-running threadpool work which would otherwise grab that idle thread.

details https://github.com/dotnet/runtime/pull/104972#discussion_r1681759430

dotnet-policy-service[bot] commented 1 month ago

Tagging subscribers to this area: @mangod9 See info in area-owners.md if you want to be subscribed.

kouvel commented 2 weeks ago

The frequency of completing tasks flagged as long-running would have to be large for this to be worthwhile. Also relevant may be separating the concept of "long-running" between "long-running-blocking" and "long-running-cpu-bound", as the latter types of work items might complete more frequently than the former, and the former types of work items may not complete at all. The blocking work items probably shouldn't go into the thread pool. The cpu-bound work items could probably be better handled by the thread pool.