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.hol...@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,
