Hi Christian,
On 8/08/2016 9:16 AM, Claes Redestad wrote:
Hi Christian,
have you looked at java.util.concurrent.ForkJoinPool.commonPool()?
That isn't quite the same thing as a general shared executor.
/Claes
On 2016-08-08 00:51, Christian Schulte wrote:
Hello,
whenever I need to update an existing codebase to add some kind of
parallelization, I am in the need of an executor matching the number of
processors available at runtime. Most of the time I end up using
something like:
'Executors.newFixedThreadPool(Runtime.getRuntime().availableProcessors())'
If every library used by an application needs to maintain its' own
executors the application ends up with starting number of libraries used
times number of available processors threads. That does not scale. I
Libraries in general should not be defining how their functionality gets
executed. If a "library" is really a subsystem that might
utilize/benefit-from parallelization then it should not encapsulate/hide
that aspect but make it explicitly part of the initialization API for
itself ie it should be able to accept an Executor/ExecutorService to
use. Ultimately it is the application that has to try and control these
things, so libraries must provide API's to allow for cooperation with
their hosting applications.
The default FJPool was a special case to support the parallel streams
libraries. It is not an ideal solution.
My 2c.
Cheers,
David
think there really is a need for some kind of default executor provided
by the platform. I am suprised I cannot find anything like that
anywhere. I would like to request an enhancement providing such a
default platform executor everyone can use to add parallelization
without ending up with tons of threads when all you want is making use
of the system's parallelization capabilities.
Regards,
