Executors enhancement
Brian Goetz
brian.goetz at oracle.com
Mon Aug 8 00:04:13 UTC 2016
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.
> On Aug 7, 2016, at 5:00 PM, David Holmes <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.
>
>> /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,
More information about the core-libs-dev
mailing list