FJ parallelism zero

[Brian Goetz]

No recollection why we didn't do this in the first place!  In fact, I 
don't recall where the -1 came from.  The docs for FJP say:

      * @param parallelism the parallelism level. For default value,
      * use {@link java.lang.Runtime#availableProcessors}.

so I'd assumed that for single-core, we'd set to 1 and it would create a 
pool with (usually) one thread, and the zero option is "I really want no 
pool", mostly for those who have to be in control of all thread 
management (like EE containers.)

On 8/6/2013 11:43 AM, Doug Lea wrote:
> 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
>