Use availableParallelism, not cpus().length when determining max workers

[bdurette]

Resolves #568

The os.cpus() documentation explicitly recommends against using that function for determining the resources available to your process. This is, among other things, because it is not container-aware. Instead, we use availableParallelism when running outside the browser, which is the recommended alternative.

[josdejong]

Thanks Brandon, good idea to use availableParallelism() instead of cpus().

One thought: I see availableParallelism was introduced in Node.js v18, which has reached its end of life for quite some time now. Still, I think it would be neat to fallback to using .cpus() in case .availableParallelism isn't available, to keep things backward compatible. Only for the library code, not needed for the unit tests. What do you think?

[bdurette]

I think it would be neat to fallback to using .cpus() in case .availableParallelism isn't available, to keep things backward compatible. Only for the library code, not needed for the unit tests. What do you think?

I'm not opposed to that. Whatever you prefer is fine. I had implemented that in my first commit and then backed that out, because it added some complexity -- especially if I needed to test that fallback.

Take a look. If that looks good to you, we can roll back that latest commit that takes out the fallback easy enough.

[josdejong]

Ah, I see your first commit. That is indeed what I mean, though I think I would write it like os.availableParallelism ? os.availableParallelism() : os.cpus().length but that is a matter of preference.

I indeed prefer keeping the backward compatibility, but I'm OK with not adding tests to validate that this fallback works (that would require mocking os or running on a very old node.js version I guess).