Hello,
yes, an ExecutorService or Executor or ForkJoinPool depending on the
minimum requirements you have.
As a default you can eithter use
ForJoinPool.commonPool() or Executors.newSingleThreadExecutor() or a
DirectExecutor() if you dont want to handle the null case special.
BTW: little nit, I
Am 08/09/16 um 19:04 schrieb e...@zusammenkunft.net:
> So it is a good idea to find a good shared default, but an API quite
> seldomly can isolate itself and the users about those aspects. So always
> allow to provide an alternate Executor. This also helps with thread
> naming, thread context,
On 10/08/2016 2:37 AM, Christian Schulte wrote:
Am 08/08/16 um 02:04 schrieb Brian Goetz:
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
Am 08/09/16 um 19:04 schrieb e...@zusammenkunft.net:
> This is nice in theory but has a number of drawbacks. First of all the
> common pool is not very easy to configure. It takes the available CPUs
> and if you run more than one VM you overcommit. Secondly different
> strategies to deal with
This is nice in theory but has a number of drawbacks. First of all the common
pool is not very easy to configure. It takes the available CPUs and if you run
more than one VM you overcommit. Secondly different strategies to deal with
longrunning or blocked jobs, with priority inheritance, with
Am 08/08/16 um 02:04 schrieb Brian Goetz:
> 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.
Exposing parallelization at API
Am 08/08/16 um 01:16 schrieb Claes Redestad:
> Hi Christian,
>
> have you looked at java.util.concurrent.ForkJoinPool.commonPool()?
Thanks for pointing that out. I looked at Java 7 documentation and did
not notice a common pool got added in Java 8. I will postpone any effort
on parallelization
Christian,
A number of years ago I put together two small libraries to provide access to
Apple's Grand Central Dispatch from Java. My thought was precisely to play
nicely with the host operating system, power management etc. I've often thought
something similar to fork-join's common pool that
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
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
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
Hi Christian,
have you looked at java.util.concurrent.ForkJoinPool.commonPool()?
/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
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:
13 matches
Mail list logo
