Wrapping virtual threads in predefined ExecutorService.

[Holo The Sage Wolf]

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

On Sat, Jun 17, 2023, 14:12 Attila Kelemen <attila.kelemen85 at gmail.com>
wrote:

> I'm not sure where you want to improve performance. Suppose we could
> create multiple virtual thread groups (each with an arbitrary number of
> carrier threads specified at group creation time). Assuming you have N
> cores, you could create N such groups with a single carrier thread each
> (then you somehow pin that carrier thread to a given core). Now you could
> execute virtual threads on a given core, but then you seem to lose most of
> the advantages, because virtual threads (even if they are running on the
> same core) are concurrent, so you can't really avoid synchronization at
> this point. Not to mention that you will get the overhead of virtual thread
> scheduling. I think if you really want some very low level optimization,
> then you probably have to use platform threads instead of virtual threads,
> and then write your tightly optimized code there.
>
> Andrii Lomakin <lomakin.andrey at gmail.com> ezt írta (időpont: 2023. jún.
> 17., Szo, 11:29):
>
>> Yes, that is what I intended to say.
>> I apologize for any confusion. Is there a plan to incorporate this
>> feature in the future?
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20230617/303934c1/attachment-0001.htm>