<div dir="ltr"><div>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.</div><div><br></div><div>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.</div><div><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Andrii Lomakin <<a href="mailto:lomakin.andrey@gmail.com">lomakin.andrey@gmail.com</a>> ezt írta (időpont: 2023. jún. 17., Szo, 14:00):<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Attila, <br><br>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) <a href="https://github.com/scylladb/seastar" target="_blank">https://github.com/scylladb/seastar</a>, and are demonstrated in a project I took part in myself <a href="https://www.datadoghq.com/blog/engineering/introducing-glommio/" target="_blank">https://www.datadoghq.com/blog/engineering/introducing-glommio/</a>, <a href="https://github.com/DataDog/glommio" target="_blank">https://github.com/DataDog/glommio</a> (written in Rust). The results have been quite noticeable in practice.<br></div><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><br></div></div></div></div>
</blockquote></div></div>