[concurrency-interest] The need for a default ForkJoinPool

Kasper Nielsen kasper at kav.dk
Mon Aug 16 04:50:12 EDT 2010

On 16/08/10 00.30, Doug Lea wrote:
> On the other hand, some methods (like shutdown) on a single global
> pool could not be made accessible.
> Also, as implied by Tim, having a single global pool invites
> surprise and unhappiness when unknown other parts of a system
> are abusing it -- for example running tasks that never terminate
> or lock themselves up.

Im not to worried about this. Is somebody going to mess up with a single 
global pool. Of course, but there will always be badly written code that 
locks up the system, leaks memory etc. And I don't except problems with 
misuse of a single threadpool will be too hard to track down. A simple 
profiler should do. IMHO things such as memory leaks/classloading issues 
are 10 times more difficult to track down.

Besides it is not like we do not already have en single global 
threadpool in Java. A single instance 
AsynchronousChannelProvider.provider() was introduced via JSR 203. The 
class wraps an Executor and ScheduledExecutorService internally.

And other platforms also share single threadpools. .NET Parallel 
Extensions/PLINQ uses a single (pr CLR instance) shared threadpool for 
their Parallel.Invoke/Parallel.For/... constructs. OSXs Grand Central 
Dispatch uses a single system wide thread-pool. And i expect that 
languages such as Scala/Groovy/X10 also has a single shared threadpool 
for their various parallel constructs.

> It might be reasonable to compromise along the lines you suggest
> -- to have a default one (that we would need to support by somehow
> disabling shutdown etc), so that people at least knowingly expose
> themselves to the risks.
We might also want disable the various setXXX methods of ForkJoinPool or 
least put some security checks in there.


More information about the Concurrency-interest mailing list