On Thu, 12 Oct 2023 16:53:12 GMT, Doug Lea <d...@openjdk.org> wrote:
>> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 3153:
>>
>>> 3151: public <T> ForkJoinTask<T> submit(Callable<T> task) {
>>> 3152: ForkJoinTask<T> t =
>>> 3153: (Thread.currentThread() instanceof ForkJoinWorkerThread) ?
>>
>> @DougLea Won't we need to check if the submitting thread belongs to the same
>> pool here?
>
> No, but I can imagine this being the subject of a Puzzler someday, because
> either choice might be unexpected by someone! To maximize compatibility wrt
> incompatible specs (initial FJ and ES), calls to submit from workers are by
> default noninterruptible, even if they are client calls into another pool.
> The opposite choice might be more defensible but could break existing code.
@DougLea Ok, that's good to know. đź‘Ť
>> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 3324:
>>
>>> 3322: poolSubmit(true, f);
>>> 3323: }
>>> 3324: for (int i = futures.size() - 1; i >= 0; --i)
>>
>> @DougLea Might not be necessary for performance, but using an ArrayDeque and
>> using `pollLast()` might be cleaner?
>
> This was a good enough idea that I started doing it until
> realizing/remembering that ArrayDeque doesn't implement List so can't be used
> here (without making a copy). Oh well.
@DougLea Ouch—I completely missed that it is also returned. Apologies :(
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/14301#discussion_r1357174453
PR Review Comment: https://git.openjdk.org/jdk/pull/14301#discussion_r1357172338
