On 8/08/2016 10:04 AM, Brian Goetz wrote:
David is right about common pool not being a general-purpose executor.
However, its intent is slightly broader than “just for streams”; it is
intended as a general-purpose FJ Pool for any library that wants to spew
parallel calculations into a shared FJPool and be a good citizen.
Creating multiple FJPools without a coordinated global resource
management strategy is likely to be suboptimal.
If a library wants to offer a customization point where it accepts an
FJPool, clients should be encouraged to pass the common pool (and the
common pool is a good default) unless there are specific reasons not to.
Good points Brian!
I'll also add that being a special kind of Executor FJPool has already
hard-wired some of the many configuration/policy choices that an
arbitrary Executor may have. The level of configurability makes it hard
to define a common shared Executor instance for general-purpose use.
Cheers,
David
On Aug 7, 2016, at 5:00 PM, David Holmes <david.hol...@oracle.com
<mailto:david.hol...@oracle.com>> wrote:
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,
