Opening discussion:

eroman@ wrote @  https://crbug.com/622400#c1 :

"""
> Note: special care will be taken for pools that only have 1 thread
> (e.g. webcrypto) and were merely used as a way to get access to
> ShutdownBehavior logic from a single-thread (I think..?). 

The WebCrypto design constraints at the time were needing a sequenced runner, and for tasks to not be joined at shutdown.

Also note that this threadpool is running in the *renderer* process.

Some of those dependencies have since changed, and I am in the process of updating documentation around this and checking the implementation (https://codereview.chromium.org/2088323002/).

The good news is I *believe* we can drop these requirements and go full-blown ExecutionMode::PARALLEL using your new TaskScheduler.

This would be helpful in fact, since right now the single threadedness of WebCrypto is problematic for consumers wanting to do bulk operations and saturate their CPU. But at the same time I was reluctant to simply let web sites have unfettered control and make things unresponsive, and was mulling with crazy ideas like  issue 615133 .

The TaskScheduler seems like it could solve this. Just note that the quantity and types of these tasks are directly controlled by users through Javascript
"""

This is not relevant until TaskScheduler runs in renderers, but this use case could help expedite making that so.

Also, regarding "throughput mitigation" (re. DHCP's threading requirements from [1]), we could have TaskTraits on PARALLEL TaskRunners to indicate maximum number of parallel tasks. Or, in fact, we will probably need to have the TaskScheduler be aware of a TaskRunner that posts way more PARALLEL tasks than average and de-prioritize it somehow so it doesn't flood the system.
PS: High workload/etc. is the precise reason TaskScheduler won't initially support the renderer (initially focusing on scheduling I/O in the browser process).

[1] https://codereview.chromium.org/2077413009/diff/20001/net/proxy/dhcp_proxy_script_fetcher_win.cc#newcode62