Question Regarding JEP 444: Virtual Threads and Use of ForkJoinPool

Olivier Peyrusse kineolyan at protonmail.com
Thu Jun 15 08:59:44 UTC 2023


To better understand the issue, I suggest reading the metaphor of this comment https://github.com/junit-team/junit5/issues/3108#issuecomment-1520174615
Yes, JUnit uses its own pool but there are unfortunate interactions across pools.
You mention that Thread.currentThread() returns a special object, so it should be ok to avoid this sort of issues.
I am still working on an example, to validate this.

Thanks for the answer

------- Original Message -------
Le mercredi 14 juin 2023 à 14:49, Alan Bateman <Alan.Bateman at oracle.com> a écrit :


> 
> 
> On 14/06/2023 13:33, Olivier Peyrusse wrote:
> 
> > And following on this question regarding FJP, is there any possible interaction between the virtual threads and any library externally using ForkJoinPools?
> > 
> > I am asking this question with this JUnit issue in mind https://github.com/junit-team/junit5/issues/3108
> > For example, if a test were to be executed by JUnit executor relying on the FJP, and if the test were using Virtual Threads, would we see interactions between those Virtual threads and JUnit executor, particularly through the test `thread instanceof ForkJoinWorkerThread`?
> > 
> > I am trying to build an example to see how the two will interact and see with my own eyes.
> 
> 
> Thread.currentThread() will return the Thread object for the virtual
> thread, it won't return the underlying ForkJoinWorkerThread used as the
> carrier.
> 
> I'm not sure how to read the referenced issue. Does JUnit's parallel
> executor create its own ForkJoinPool to run tests or does it use the
> common pool? In any case, it will be a separate pool to that used for
> virtual threads.
> 
> -Alan


More information about the loom-dev mailing list