Question Regarding JEP 444: Virtual Threads and Use of ForkJoinPool

[Alan Bateman]

On 15/06/2023 09:59, Olivier Peyrusse wrote:
> To better understand the issue, I suggest reading the metaphor of this comment https://urldefense.com/v3/__https://github.com/junit-team/junit5/issues/3108*issuecomment-1520174615__;Iw!!ACWV5N9M2RV99hQ!JfFotlDxfQKbajArMCeX6jDH4hC98_i1yXeaDD-e2Q1g8Q4krIV3iboQ-IkbFmW8rW0twuGaQ8TCkNcQ8Xypoqw$
> 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.
>
"special object" = the Thread object representing the current Thread.  
If the test executor is looking at Thread.currentThread when I wouldn't 
expect any issues or interaction. However, if it's enumerating all 
platform threads, say with Thread.getAllStackTraces or 
ThreadMXBean.getAllThreadsIds, and assuming all ForkJoinWorkerThreads 
are controlled by the test executor, then it may get confused by other 
FJ worker threads.

-Alan