[concurrency-interest] The need for a default ForkJoinPool
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