Executors enhancement

[David Holmes]

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.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.
>>
>>> /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,
>