As of right now, there is a universal flag for SabreTools that sets the maximum number of threads that any parallel action can use. On versions of .NET newer than Framework 4.5.2, this value is used. On version Framework 4.0, there is no ability to set desired threads but work is still done in parallel. All versions lower (Framework 2.0, Framework 3.5) do not have the ability to do parallel operations that way and ignore all threading entirely.

It is worth noting that the functionality to even include the threading flag is already framework version gated, so that does not factor in as a "wasted flag" in old .NET.

The discussion here is whether or not having this maximum thread count flag is still considered useful. Here are the arguments that I have on both sides:

Keep

• Controlling the thread count can help in scenarios that are memory sensitive
• Ability to enable single-threading for testing is valuable
• The default maximum thread count of one thread per core is reasonable
• Explicit thread counts can make it easier to reproduce issues

Remove

• Removes some adaptive memory management from the framework
• Potentially misrepresents the amount of work that the program can do, possibly making memory consumption worse
• Requires not-insignificant amounts of care to deal with multiple framework-dependent paths
• Requires user input if the default values are not accurate, unlike relying on the framework