Executors enhancement

[David Holmes]

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