Single Thread Continuation

[Robert Engels]

I would fully avoid all of these isolated use case. Virtual threads solves the primary need for Java - thread per connection. 

All of these other uses can be done in other languages - don’t pollute Java with less useful idioms that solves peoples need to not have to learn CS. 

> On Jul 2, 2023, at 4:16 PM, Ron Pressler <ron.pressler at oracle.com> wrote:
> 
> Hi.
> 
> While we want to offer generators, which are a thread-confined form of continuations, we would also like to offer custom virtual thread schedulers, which would be even more powerful and general for the kind of usage you have in mind.
> 
> 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.
> 
> So until we get around to custom schedulers, using the default scheduler and the java.util.concurrent synchronisation constructs is the reasonable thing to do.
> 
> — Ron
> 
> 
>> On 2 Jul 2023, at 10:07, Øystein Myhre Andersen <o.myhre at gmail.com> wrote:
>> 
>> I think I remember that it was mentioned a while ago that Continuation will perhaps be introduced again in a 'single thread' version.
>> This is what I need to implement Quasi Parallel systems in Simula.
>> Now I use virtual threads and semaphore to achieve the same. But it seems a bit exaggerated when I know that Continuation is in the background.
>> 
>> 
>> 
>> 
>> Anyone know anything about this ?
>> 
>> 
>> 
>> - Øystein Myhre Andersen
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>