FJ parallelism zero

Doug Lea dl at
Tue Aug 6 08:43:47 PDT 2013

Oops. First posted without the "-libs"

On 08/06/13 11:42, Doug Lea wrote:
> Mostly to Brian, but other thoughts welcome:
> As a compromise of sorts with the EE folks, we allow the
> ForkJoinPool.commonPool to be set to parallelism zero
> via a system property. We by default set to
> Runtime.availableProcessors()-1.
> All the Stream stuff can handle parallelism zero
> (in these cases, the submitter ends up executing
> all the subtasks).
> But when the ForkJoinPool.commonPool is used for
> purely async stuff, it is surprising at best that
> tasks may never run unless somehow joined or the submitter
> takes some alternative action (which we sometimes do in
> other JDK usages of commonPool).
> I think the EE folks are in general OK with the
> surprise. But not so for those few people out
> there running JDK8 on uniprocessors, with default
> configurations, that also end up setting parallelism
> to zero. So unless anyone can think of a reason
> otherwise, I'm going to change to minimum parallelism
> of one unless set to zero by system property.
> (Brian: do you have any recollection of why we didn't
> do it this way in the first place?)
> -Doug

More information about the lambda-libs-spec-observers mailing list