[concurrency-interest] The need for a default ForkJoinPool
kasper at kav.dk
Mon Aug 16 05:15:45 EDT 2010
On 16/08/10 01.50, David Holmes wrote:
> Kasper Nielsen writes:
>> Having used the FJ classes for a couple of libraries. The one thing that
>> is really annoying me is the fact that there are no default ForkJoinPool
>> I can use.
>> If you are designing a library a.la. a parallel ju.Arrays library that
>> uses the FJ classes. You have two choices: either you can create a new
>> ForkJoinPool and use it internally in your library. Or you can ask the
>> user to provide one, something like sort(ForkJoinPool pool, int
>> array). And I really don't like any of the alternatives.
> I think as a library provider you must do the latter. You can't assume that
> you know how pools should be created or used, so all you can do is have the
> user supply you with one. I understand this is somewhat awkward as you don't
> necessarily want this on every method that is an entry-point to your
> library; nor is it usual to have an explicit "init" method for a library,
> that could be used to set this. But you need some technique for the library
> user to "configure" your library with regard to the pool to be used. It may
> also be that different parts of the application may want to use your library
> with different underlying pools - again indicating the user must supply the
> pool to be used somehow.
> I do agree that there should be a default pool easily accessible to the
> user - and created only on demand - but other libraries should only use that
> default as a fall-back for when the user does not provide one, or uses the
> library in a way that says "use the default pool for this" - the user has to
> have the control here.
> David Holmes
I agree, for my particular use I have a setForkJoinPool method. I just
suspect that 95 % of users will never use it. And I really don't want to
make my library more complex then it already is, by requiring them to
always set one.
More information about the Concurrency-interest