[concurrency-interest] The need for a default ForkJoinPool

Joe Bowbeer joe.bowbeer at gmail.com
Mon Aug 16 14:56:12 EDT 2010

Other background services that are managed by default:

SwingWorkers share a single executor (with no option to configure another
one, unfortunately)

RMI & gc

For things like SwingWorker, which is a fundamental service in some contexts
and a layered service in other contexts, I would like to have a convenient
default available, but I would also like the ability to configure my own.


On Mon, Aug 16, 2010 at 1:50 AM, Kasper Nielsen wrote:

> 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.
> Cheers
>  Kasper
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20100816/4f24a773/attachment.html>

More information about the Concurrency-interest mailing list