[concurrency-interest] Adding ForkJoinPool.setPoolSizeLimit

√iktor Ҡlang viktor.klang at gmail.com
Thu Jan 12 15:45:26 EST 2012

2012/1/12 Doug Lea <dl at cs.oswego.edu>

> As I was just reminded, one benefit of FJP currently
> NOT having dynamic configuration methods is that
> different parts of a system all using the same FJP
> cannot hurt each others usages by changing settings
> in a way that only work well for one part. This
> benefit seems worth preserving.
> Which makes an alternative (once suggested by Viktor
> and others) that doesn't expose control more attractive:

Yeah, this is very nice.

> There already is a way to limit pool size: Use a
> ForkJoinPool.**ForkJoinWorkerThreadFactory that returns
> null when it doesn't want to create additional
> threads due to resource constraints. FJP copes
> with null returns from ForkJoinWorkerThreadFactory.**newThread,
> and does so reasonably cheaply (which can/will be
> made a bit cheaper still). Because the pool
> is provided as an argument to newThread, the
> factory can check the current size and state when
> doing so.

Excellent tip.

> For management and monitoring purposes this option
> would be nicer if ForkJoinWorkerThreadFactory had
> a second method
>  void terminated(**ForkJoinWorkerThread w)
> that is invoked when a worker thread is terminated.

Sounds like Pool-style behavior, cool.

> Only full termination seems possible -- we cannot reuse
> these threads unless we change specs about
> UncaughtExceptionHandlers, etc.
> And anyway, creation/termination cycles tend to be long
> enough in FJ that the extra bookkeeping necessary to reuse vs
> recreate would rarely pay for itself.
> Because ForkJoinWorkerThreadFactory is a nested
> interface, doing this would be reasonably straightforward.
> We could define:
> public static interface ManagedForkJoinWorkerThreadFac**tory
>  extends ForkJoinWorkerThreadFactory {
>  void terminated(**ForkJoinWorkerThread w);
> }
> And then add a few instanceof checks internally
> to invoke terminated() if the provided factory
> supports it.
> If we take this option, then we should further consider
> any other methods to add to this subinterface while we are
> at it. Suggestions welcome.
> Note though that even without a termination callback,
> the existing mechanics above can minimally suffice (although
> in a messier way), because of the opportunity for status probes
> inside method newThread -- the main limitation is that these
> queries can tell you only how many threads there are, but not
> which threads are still alive.
> Some replies:
> On 01/12/12 09:57, √iktor Ҡlang wrote:
>  1) Should there be any possible backpressure for the FJP?
> Do you have something in mind beyond the things I mentioned above?

Nevermind, I've already come up with a way to solve this on a higher level

>  2) What's the current behavior for submissions during shutdown?
> The same as ThreadPoolExecutor. Upon shutdown, no new
> submissions are accepted but existing tasks are processed
> until the pool is quiescent, at which point it terminates.

We're talking RejectedExecutionException? If so, then that's completely
fine with me.


> -Doug

Viktor Klang

Akka Tech Lead
Typesafe <http://www.typesafe.com/> - The software stack for applications
that scale

Twitter: @viktorklang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120112/eec21a69/attachment.html>

More information about the Concurrency-interest mailing list