Single Thread Continuation

[Mark Raynsford]

On 2023-07-02T21:15:29 +0000
Ron Pressler <ron.pressler at oracle.com> wrote:
>
> 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.

I feel obligated to bring this up every time the subject appears: One
important use case for me is being able to decompose code into a number
of concurrent tasks, but without also having to deal with the
complexity of parallelism-related data hazards.

In other words, I'd like to be able to use a set of virtual threads
that are guaranteed to be scheduled on a single platform thread.
This is a common approach used inside language interpreters embedded
into game engines (typically Lua, although I hear C# is seeing use for
this too nowadays).

Game engines and simulations tend to comprise a large number of
concurrent tasks, and much of the time those tasks need to access
complex mutable state that is very difficult to reliably make
thread-safe. Additionally, most of the time it's desirable for it
to be possible to pause and resume the execution of individual tasks.

Being able to map each task to a virtual thread, but have
those virtual threads execute on a single platform thread would
solve the problem in a very natural and pleasant way. Additionally,
we'd get the ability to pause and resume a task without it losing its
stack for free. Normally, that kind of thing has to be implemented
manually.

I agree it's definitely less mainstream. Most of the code I write isn't
like this, but some of it is, and it desperately needs the mechanism
that virtual threads don't quite provide yet. An early version did
allow for specifying an executor service, but this was obviously taken
out.

-- 
Mark Raynsford | https://www.io7m.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20230703/c28cdaf3/attachment.sig>