Wrapping virtual threads in predefined ExecutorService.

[Andrii Lomakin]

As for the usage of virtual threads in the UI event loop.
JetBrains utilizes virtual threads in the Compose Multiplatform UI
architecture's event loop. Kotlin coroutines accept the dispatcher (or
carrier thread/pool) and provide await functionality (as you mentioned
above).
But, correct me if I am wrong, channels can also achieve the same effect of
allowing other processes to be carried out while waiting.

On Sat, Jun 17, 2023 at 1:47 PM Attila Kelemen <attila.kelemen85 at gmail.com>
wrote:

> I agree that it would be useful for a couple of reasons. For example to
> reduce the maximum latency. I just don't see the benefit for such a tight
> low level optimization. As for UI: It wouldn't be useful I think, because
> the UI frameworks are single threaded to avoid synchronization need, and
> you can't really have that with virtual threads, because virtual thread
> scheduling is not cooperative. For a UI framework (with `await` like
> functionality of other languages) you need cooperation where you
> effectively tell the framework that "while I'm waiting here, you can
> process other things". That would - I believe - require the exposal of
> continuation, or some specific support.
>
> Holo The Sage Wolf <holo3146 at gmail.com> ezt írta (időpont: 2023. jún.
> 17., Szo, 13:34):
>
>> The ability to mound virtual threads on a specific thread pool(/executor)
>> is quite useful in general.
>>
>> Practically all applications with UI will want a designated thread pool
>> for UI Vs the rest.
>>
>> CPU heavy applications may want to use OS threads for most of the
>> application, but have 1/2 threads on the side to handle e.g. incoming
>> request, put them in a queue for the CPU heavy process, and wait for it to
>> finish before sending it onwards/returning a status.
>>
>> In these cases the ability to use virtual threads on the part of the
>> application that it fits without interfering the other parts is currently
>> impossible.
>>
>> As for the thread-per-core case, I don't see an immediate reason not to
>> use virtual threads over e.g. event loop, but I will admit that the low
>> level stuff is my weaker side
>>
>>>
>>>>

-- 
Best regards,
Andrii Lomakin.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20230617/3fe9f0f4/attachment.htm>