Support millions of coroutines.
So if it's possible to have a choice, that sounds great, but if not, choose
a more scalable implementation if only one can be done. Making coroutines
effectively as cheap as other objects for managing state opens up their
usage, and it would also be competitive in t
Yes, the best will be to have the choice, i.e two different Java objects
or a way to select if you want to share the stack between coroutine or not.
Rémi
Attila Szegedi a écrit :
> As coroutines are often employed in situations where massive parallelism is
> desired, I believe that the approach
As coroutines are often employed in situations where massive parallelism is
desired, I believe that the approach that allows millions of them is the better
choice, if a single choice has to be made.
That said, if there is a meaningful way to have the programmer choose between
the two models (or
Hi everybody!
I would be very interested to hear what the expectations for a coroutine
implementations for Java are. I am asking because I am facing some
initial design decisions on my way.
There is a quite simple tradeoff between memory/address space usage and
execution speed:
* Using "tradit
