[concurrency-interest] ForkJoinPool not designed for nested Java 8 streams.parallel().forEach( ... )
viktor.klang at gmail.com
Tue May 6 15:24:18 EDT 2014
On Tue, May 6, 2014 at 8:18 PM, Doug Lea <dl at cs.oswego.edu> wrote:
> On 05/06/2014 01:54 PM, √iktor Ҡlang wrote:
>> The current default is to only generate a new thread if saturated,
>> which is the most conservative possible policy. If we allowed a
>> bound on compensations, then everything could freeze up if past
>> some arbitrary limit, which seems even less popular than risking
>> OutOfMemoryError (and RejectedExecutionException) thrown by
>> attempted Thread construction. Especially since you can use
>> ForkJoinWorkerThreadFactories and/or SecurityManagers or to bound
>> the total number of Threads in a program, whether by FJ or elsewhere.
>> Assuming that there are other threads in the system than the pool, it'd be
>> perfectly fine to have all threads in the pool stalled when waiting for
>> threads to complete/signal progress, right?
> This might hold in practice in some applications and frameworks,
> but not in general: these other threads may be using FJ and blocking
> on results.
There's definitely the risk of reentrancy.
>> How can ForkJoinWorkerThreadFactory be used to cap the maximum number of
>> without blowing something up?
> Create a factory that hands out up to a maximum number of threads,
> else null. So long as it provides at least as many threads as
> the parallelism level, then nothing blows up when null is returned
> thereafter. (You'd also need some bookkeeping in
That sounds fair enough, I'll give it a try. Thank you!
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest