<div dir="ltr">Fibers/continuations are very good but if you are developping a software in java using many libraries is complicate to realize a optimized software because third-parties libraries are full of locks thinking to concurrent working with threads , not fibers. Locks are  time comsuming alot for CPU. If you use continuations you should  for my opinion review all the code where you use locks.<div>In the past i m beginning a project for replacing all the locks with optimized code for continuation using instrumentation (so also third-parties libraries get optimized) . No time for finishing. </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Il giorno lun 3 lug 2023 alle ore 13:07 Andrii Lomakin <<a href="mailto:lomakin.andrey@gmail.com">lomakin.andrey@gmail.com</a>> ha scritto:<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">Mark.<div>Thank you for raising this point. It is important not only from a gaming development perspective, but such an approach could bring benefits in the case of database development, too, for the same reason.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jul 3, 2023 at 12:45 PM Mark Raynsford <<a href="mailto:org.openjdk@io7m.com" target="_blank">org.openjdk@io7m.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2023-07-02T21:15:29 +0000<br>
Ron Pressler <<a href="mailto:ron.pressler@oracle.com" target="_blank">ron.pressler@oracle.com</a>> wrote:<br>
><br>
> However, it’s important to remember that our priorities are primarily shaped by Java’s role as a *mainstream* platform and the demands of *mainstream* usages. In other words, what drives up the priority of the feature is not its hypothetical power but its potential use in mainstream applications because that’s where most of the value is, considering the majority of Java’s users. The more mainstream something is, the higher its priority. Given that custom schedulers address less mainstream uses than the default scheduler, they’re on the roadmap but not our highest priority at the moment.<br>
<br>
I feel obligated to bring this up every time the subject appears: One<br>
important use case for me is being able to decompose code into a number<br>
of concurrent tasks, but without also having to deal with the<br>
complexity of parallelism-related data hazards.<br>
<br>
In other words, I'd like to be able to use a set of virtual threads<br>
that are guaranteed to be scheduled on a single platform thread.<br>
This is a common approach used inside language interpreters embedded<br>
into game engines (typically Lua, although I hear C# is seeing use for<br>
this too nowadays).<br>
<br>
Game engines and simulations tend to comprise a large number of<br>
concurrent tasks, and much of the time those tasks need to access<br>
complex mutable state that is very difficult to reliably make<br>
thread-safe. Additionally, most of the time it's desirable for it<br>
to be possible to pause and resume the execution of individual tasks.<br>
<br>
Being able to map each task to a virtual thread, but have<br>
those virtual threads execute on a single platform thread would<br>
solve the problem in a very natural and pleasant way. Additionally,<br>
we'd get the ability to pause and resume a task without it losing its<br>
stack for free. Normally, that kind of thing has to be implemented<br>
manually.<br>
<br>
I agree it's definitely less mainstream. Most of the code I write isn't<br>
like this, but some of it is, and it desperately needs the mechanism<br>
that virtual threads don't quite provide yet. An early version did<br>
allow for specifying an executor service, but this was obviously taken<br>
out.<br>
<br>
-- <br>
Mark Raynsford | <a href="https://www.io7m.com" rel="noreferrer" target="_blank">https://www.io7m.com</a><br>
<br>
</blockquote></div><br clear="all"><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr">Best regards,<br>Andrii Lomakin.<br><br></div></div></div></div>
</blockquote></div>