Virtual threads and executor ?
forax at univ-mlv.fr
forax at univ-mlv.fr
Fri Nov 19 18:26:15 UTC 2021
----- Original Message -----
> From: "Ron Pressler" <ron.pressler at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "loom-dev" <loom-dev at openjdk.java.net>
> Sent: Jeudi 18 Novembre 2021 21:53:31
> Subject: Re: Virtual threads and executor ?
> The rationale is simple: that mechanism is much less mature than others because
> we’ve focused on higher-priority items that are relevant to more people, and
> so, while we’re working on it, we don’t want to hold up the rest of the
> features in the project, so we took it out until we feel comfortable enough
> with its design and operation.
I'm not sure to understand what design really encompass here given that a virtual already take an executor.
For me, this decision will hamper the adoption of Loom, because it's now harder to use virtual thread where previously platform thread were used,
you can not simply swap the executors to use a virtual thread executor.
Anyway as an exercise i've re-implemented ExecutorService on top of StructuredExecutor,
(obviously the implementation is quite awful [1]) but the code of my proxy now works !
>
> — Ron
Rémi
[1] https://github.com/forax/loom-fiber/blob/master/src/main/java/fr/umlv/loom/executor/VirtualThreadExecutor.java
>
>> On 18 Nov 2021, at 19:22, Remi Forax <forax at univ-mlv.fr> wrote:
>>
>> In the latest refresh of loom, a user can not set the executor anymore.
>> That's an issue because existing codes tend to use an executor so the
>> refactoring to introduce virtual threads is now harder.
>> The other issue I have is that i can not create a virtual thread on a non-daemon
>> thread anymore, so i have a code of a proxy that terminates too early when
>> using virtual threads.
>>
>> What is the rational behind not letting a user to specify an Executor when
>> creating a virtual thread ?
>>
>> regards,
> > Rémi
More information about the loom-dev
mailing list