Bug Start-ThreadJob not pooling and hidden global constant

[agowa]

Steps to reproduce

$a = {Start-Sleep -Seconds 100;Write-Host "sleep 100 - 1st"}
$b = 1..10 | ForEach-Object { Start-ThreadJob -ScriptBlock $a -ThrottleLimit 2 }
$c = 1..10 | ForEach-Object { Start-ThreadJob -ScriptBlock $a -ThrottleLimit 10 }
$b

Expected behavior

ThrottleLimit should either only apply for the one line it was specified with e.g. the one that fills $b and the other one for those that fill $c.
But that may be hard to impossible, as it would require the command within the scriptblock of the foreach knowing about the piping and even than it would break in countless of other cases.

The better fix may be adding a "ThreadPool" parameter that allows "ThrottleLimit" to just apply to that pool of threads, as well as documenting within the Get-Help pages that ThrottleLimit changes a global constant and that it influences already scheduled tasks.

A third possible fix would be to store the ThreadLimit with the ThreadJob id and compare the amount of currently running threads against the limit of the next one in the list (basically if 4 tasks already run and task 5 should be started, it simply could be checked what the ThreadLimit of task 5 is and if lesser Threads are currently running). This would introduce an implicit synchronization, as all tasks of b would complete before any of the ones within $c will start, but as the tasks are currently also processed using FIFO this may be the best fix. Using this approach all tasks within $b will be started using a ThreadLimit of 2, except the last one, that will be started using the ThreadLimit of $c. E.g. it will run together with the first 9 tasks of $c. This however is not an issue, as 9 is below the expected limit of 10. And also for the tasks in $b 1 is also below the there defined limit of 2. If the limit of a later task is smaller, it simply will not start until enough of the previous tasks have completed.
And the implementation of ThreadPools for Start-ThreadJob could be put into the backlog for being implemented with the next version.

When dealing with different APIs, the current behaviour could lead to unexpectedly running into rate limitations.
E.g. if $b contains threads to the API of e.g. https://example.com/ with a strict rate limit of 2 and $c contains threads querying the api of https://contoso.com/ with a less strict rate limit of 10

Actual behavior

The ThrottleLimit apparently changes a global constant which influences how many threads within $b are started, even though it was specified for $c.

Environment data

Name                           Value
----                           -----
PSVersion                      7.0.3
PSEdition                      Core
GitCommitId                    7.0.3
OS                             Microsoft Windows 10.0.20190
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

[iSazonov]

It looks like overhead to have many pools because resources are related to a computer.

[agowa]

I just provided multiple possibilities for an implementation. My personal favourite is the 3rd one:

A third possible fix would be to store the ThreadLimit with the ThreadJob id and compare the amount of currently running threads against the limit of the next one in the list (basically if 4 tasks already run and task 5 should be started, it simply could be checked what the ThreadLimit of task 5 is and if lesser Threads are currently running).

[agowa]

No Auto close, Feature Request is still not implemented. Wtf?!? Do I need to write a bot that auto replies to keep my Tickets open now?