Avoiding Side Effects of ForkJoinPool.managedBlock

[Johannes Spangenberg]

> On the REE, this is also controlled by JUnit when it creates the FJP.
> The saturate parameter is the predicate that is determines if REE is
> thrown or the pool continues without an additional thread.

Thanks, I missed that unfortunately. My version of JUnit uses null for
the saturate parameter, but it has been changed in more recent versions.

https://github.com/junit-team/junit5/commit/324802d8d0e189a4bddac5a2f93e4c52d2431f5b

So, I guess (2.) and (3.) can be fixed by using a more recent version of
JUnit... Regarding (1.), I suppose there is no option to disable the
thread-stealing mechanism with parallel streams. I find it a bit
unfortunate that using a ForkJoinPool changes the behavior of various
methods which are otherwise unrelated to the ForkJoinPool. (Maybe
virtual threads can be used to fix that at some point.) Anyway, I have
everything I need right now.

Thank you again,
Johannes

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 7798 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20240118/debde760/smime-0001.p7s>