Update copy logic to use dedicated threads.

[Erarndt]

Also updated some checks to help avoid hitting the file system if possible.

Fixes #

Context

The existing implementation does synchronous file copying on threadpool threads which can lead to starvation. Switching to dedicated threads to do synchronous copying helps keep the threadpool threads available for other tasks.

Changes Made

Testing

Notes

[rainersigwald]

Just kinda generally, I'm surprised to hear about threadpool starvation in our worker nodes which aren't threadpool heavy. Have you observed this in practice?

[Erarndt]

Just kinda generally, I'm surprised to hear about threadpool starvation in our worker nodes which aren't threadpool heavy. Have you observed this in practice?

There is some sneaky utilization of the threadpool that ends up blocking enough to see the "hill climbing" algorithm start spinning up new threads. I've seen between 40 and 50 threadpool threads per MSBuild processes which is over 3x what I would expect. This change (#11275) has a larger impact than the copy code, but this contributes as well. There's also additional benefit to reducing the mix of I/O bound work and CPU bound work on the threadpool.

[JanKrivanek]

Related to #11160

[JanProvaznik]

Looks reasonable, please

1. fix the test
2. cleanup parallelism parameter
3. if possible share some evidence of perf impact, I could not see it from looking at some local OrchardCore builds (albeit I did not achieve statistical significance)

[yuehuang010]

Is there an option to use TaskCreationOptions.LongRunning flag? This should avoid the thread starvation problem.

[SimaTian]

Looks good. Thank you.

[Copilot]

PR Overview

This PR updates the file copy logic to use dedicated threads to handle synchronous file copying, aiming to reduce threadpool starvation. Key changes include:

• Adding a dedicated thread pool with static thread arrays and action queues for parallel copying.
• Changing the parallelism configuration from an integer value to a boolean flag indicating whether to copy in parallel.
• Updating unit tests to reflect the new boolean-based parallelism setting.

Reviewed Changes

File	Description
src/Tasks/Copy.cs	Introduces dedicated thread pool logic and revises parallel copy execution.
src/Framework/NativeMethods.cs	Adjusts long path handling in GetFullPath using stack-allocated buffers.
src/Tasks.UnitTests/Copy_Tests.cs	Updates tests to use the new boolean parallelism flag.

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

Comments suppressed due to low confidence (1)

src/Tasks/Copy.cs:57

• Review the use of static thread pool fields to ensure they don't interfere when multiple Copy task instances run concurrently; consider using instance-based thread pools or more robust synchronization if needed.

lock (_copyActionQueue)

[JanProvaznik]

lgtm

[YuliiaKovalova]

Thank you for the contribution!
@AR-May , could you please measure the impact of the change ?

[AR-May]

Hi! Numbers:

ExecutableName	RepoName	Scenario	Mean	Median	Variance	Min	Max	EntriesNum
MSBuildBaseline	OC	inc-cold	33689.2	32643.3	11999119.992319642	29989.07	44322.37	20
MSBuildCompare	OC	inc-cold	32783.002440000004	31915.07	9742298.542851143	29628.52	40470.06	20
MSBuildBaseline	OC	re-cold	137929.7	136370.62884999998	47597265.67838404	126331.6	155266.6	20
MSBuildCompare	OC	re-cold	138762.7	137488.06410000002	157097140.4644246	125246.8	187710.1	20

I believe the performance difference is below our ability to detect it.