Virtual threads in existing FJP logic

Christian Stein sormuras at gmail.com
Sat Feb 15 21:18:58 UTC 2020


Hi Nawazish,

the issue I see is that the ForkJoinWorkerThreadFactory declares
a method newThread with ForkJoinWorkerThread as the return type.
That ForkJoinWorkerThread already extends java.lang.Thread, see
[0] for details. The API of ForkJoinWorkerThread doesn't allow
setting a virtual flag nor does the Thread.Builder help in this regard.

Cheers,
Christian

[0]:
https://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/ForkJoinWorkerThread.html


On Sat, Feb 15, 2020 at 10:57 AM Nawazish Khan <md.nawazish.khan at gmail.com>
wrote:

> Hi Christian,
>
> I believe it should be possible and doable. The Worker Thread Facrory,
> while creating Threads, should simply create Virtual Threads instead of
> java.lang.Threads.
>
> Sincerely,
> MNK
>
>
>
> On Sat, Feb 15, 2020 at 1:56 AM Christian Stein <sormuras at gmail.com>
> wrote:
>
>> Hi everybody,
>>
>> Marc and I from the JUnit team are exploring ways how to
>> integrate virtual threads into the Jupiter test engine. Today
>> we're using a FJP to enable parallel test execution.
>>
>> Find the implementation here [0], where at end of the source
>> file, you'll see our custom ForkJoinWorkerThreadFactory and
>> the custom ForkJoinWorkerThread implementation.
>>
>> My idea was to "simply" configure those custom classes to
>> create virtual threads. Is this possible? If not, we might
>> resort to add a virtual thread based implementation of the
>> HierarchicalTestExecutorService interface.
>>
>> Cheers,
>> Christian
>>
>> [0]:
>>
>> https://github.com/junit-team/junit5/blob/master/junit-platform-engine/src/main/java/org/junit/platform/engine/support/hierarchical/ForkJoinPoolHierarchicalTestExecutorService.java
>>
>


More information about the loom-dev mailing list