Wrapping virtual threads in predefined ExecutorService.

[Attila Kelemen]

I do not doubt that. I just don't think that using virtual threads can
retain that advantage (though I always reserve the right to be wrong :)).
Because the greatest benefit is coming from not needing to use locks, in
which case you can just start N virtual threads, and be probably fine.

Regardless, I would love to see support for virtual thread groups with
distinct sets of carrier threads (or anything equivalent). I just don't
think that in your case that would bring a big advantage.

Andrii Lomakin <lomakin.andrey at gmail.com> ezt írta (időpont: 2023. jún.
17., Szo, 14:00):

> Attila,
>
> While I understand and respect your opinion, I must disagree. Through
> practical examples, it has become evident that thread-per-core architecture
> and asynchronous IO are incredibly beneficial in database development.
> These techniques are used in ScyllaDb and their SeaStart framework (written
> in C) https://github.com/scylladb/seastar, and are demonstrated in a
> project I took part in myself
> https://www.datadoghq.com/blog/engineering/introducing-glommio/,
> https://github.com/DataDog/glommio (written in Rust). The results have
> been quite noticeable in practice.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20230617/0d7cf931/attachment.htm>