[concurrency-interest] The need for a default ForkJoinPool

Gregg Wonderly gregg at cytetech.com
Wed Aug 18 09:44:06 EDT 2010

Kasper Nielsen wrote:
> On 17/08/10 22.47, Gregg Wonderly wrote:
>> So, I'm still interested in what might be possible to have FJ provide
>> some level of out of band knowledge. I'm thinking about something like
>> the following in FJPool.
>> public static FJPool getThreadsPool() {
>> for( FJPool pool : allPools.elements() ) {
>> if( pool.contains( Thread.currentThread() ) != null ) {
>> return pool;
>> }
>> }
>> }
>> This would look through active instances to see if the current thread is
>> dispatched from that pool. If it is, then return the pool. This would
>> then allow a pretty low level in the software structure to find the
>> environment it might use for dispatching work, without having to pass
>> around such details through countless APIs.
> Gregg,
> I'm not sure I understand what you are trying to do.
> If the current thread is dispatch from a FJPool you can only be running 
> a ForkJoinTask in which case the pool that is executing the task can be 
> obtained via a call to static ForkJoinPool ForkJoinTask.getPool();

Yes, but a library which I have dispatched from that task to do something, in 
addition, won't have a reference to the FJTask, unless the library has some kind 
of initialization that lets me tell it what pool to use.  In this case, I want 
that library to be able to find the FJPool, and I'd even say I don't want it to 
be able to create its own instance in some cases, as I alluded to.

Gregg Wonderly

More information about the Concurrency-interest mailing list