Single Thread Continuation

[Mushtaq Ahmed]

>
> 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.


Thanks for articulating this so well. This is the exact use case we have.

I was very excited to read about the following API in early loom prototypes
but it did not make it in the final release:

Thread.builder().virtual(Executors.newSingleThreadExecutor()).factory()

Loom getting custom schedulers which allow this will be a big deal.


On Mon, Jul 3, 2023 at 4:15 PM Mark Raynsford <org.openjdk at io7m.com> wrote:

> 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 --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20230703/b892a7b1/attachment-0001.htm>