david.holmes at oracle.com
Mon Aug 8 00:11:17 UTC 2016
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.
>> On Aug 7, 2016, at 5:00 PM, David Holmes <david.holmes at oracle.com
>> <mailto:david.holmes at 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.
>>> On 2016-08-08 00:51, Christian Schulte wrote:
>>>> 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:
>>>> 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.
>>>> 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.
More information about the core-libs-dev