Wrapping virtual threads in predefined ExecutorService.

[Attila Kelemen]

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
>
>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20230617/682e2ecc/attachment.htm>