Executors enhancement

[Brian Goetz]

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,