Concurrency page lists wrong default for ThreadPoolScheduler default threads

[jmaslak]

Problem or new feature

At least on my computer, ThreadPoolScheduler defaults to 64 threads:

$ raku -e 'say ThreadPoolScheduler.new.max_threads'
64

(The $*SCHEDULER instance also is set to 64 by default, with no environment set)

However, on https://docs.raku.org/language/concurrency , under ThreadPoolScheduler, it states that it is 16:

The [ThreadPoolScheduler](https://docs.raku.org/type/ThreadPoolScheduler) is the default scheduler, it maintains a pool of threads that are allocated on demand, creating new ones as necessary up to maximum number given as a parameter when the scheduler object was created (the default is 16.)

Suggestions

If 64 is what it always is, just change this, but if not, reflect reality. :)

[dontlaugh]

The behavior seems to actually be a multiple of the number of CPUs detected.

On a beefy machine with 32 cores I get

raku -e 'say ThreadPoolScheduler.new.max_threads'
256

[dontlaugh]

I think we can remove mentioning the default at all, since it's kind of implementation- and environment-specific.

This section could be reorganized to read:

=head3 ThreadPoolScheduler

The L<C<ThreadPoolScheduler>|/type/ThreadPoolScheduler> is the default scheduler, it maintains a pool
of threads that are allocated on demand, creating new ones as necessary.

Rakudo allows the maximum number of threads allowed in the default scheduler
to be set by the environment variable C<RAKUDO_MAX_THREADS> at the time
the program is started.

If the maximum is exceeded then C<cue> may queue the code until a thread
becomes available.

[timo]

https://github.com/rakudo/rakudo/pull/4652 here's the pull request that introduced the current behaviour: 64 at least, otherwise 8 * num-cpu-cores