consider pulling long running threatpool threads from the pool

[danmoseley]

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 #104972 (comment)

[dotnet-policy-service]

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

[kouvel]

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.