[External] : Re: Virtual threads and executor ?

[forax at univ-mlv.fr]

----- 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: Vendredi 19 Novembre 2021 19:34:21
> Subject: Re: [External] : Re: Virtual threads and executor ?

>> On 19 Nov 2021, at 18:26, forax at univ-mlv.fr wrote:
>> 
>> ----- 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.
> 
> Oh, I don’t think we’re talking about the same thing. To migrate to virtual
> threads, start by replacing existing ExecutorServices with
> Executors.newVirtualThreadPerTaskExecutor/newThreadPerTaskExecutor. All that’s
> there.

The problem with Executors.newVirtualThreadPerTaskExecutor() is that you can not specify an underlying executor, all the virtual threads has to run on the default common fork/join pool but the common F/J pool is not good in all use cases (you can even specify another pool when using a parallel stream), it's just a good default.

I am all good with not having an API promising too much, but this limitation makes the integration of loom to existing libraries/stack unnecessary hard IMO.

> 
> I thought you were talking about the super-advanced feature of custom
> schedulers, which are still not mature enough, and don’t aid in migration.
> 
> — Ron

Rémi