Continuation.yield limitations

[Ron Pressler]

1. Because monitors are built into the VM to be owned by threads. Moving them between threads,
then, requires changing how they’re implemented, and that’s a significant amount of work.
We want to do that eventually, but it’s not currently supported.

2. Unlike monitors, which are a temporary limitation, this one is here to stay.
Native stack frames could contain pointers into the stack without the VM knowing about them.
This makes copying and moving continuation stacks around hard without some clever virtual
memory tricks that would diminish our flexibility in implementing continuations. Given
that this limitation does not seem to cause much pain, we might as well make it permanent.


Ron



On 4 September 2019 at 21:51:35, Arkadiusz Gasiński (jigga at jigga.pl(mailto:jigga at jigga.pl)) wrote:

> Hi,
>  
> Could someone here try to ELI5 the current limitations of
> Continuation.yield method? Specifically, why we can't yield when:
>  
> 1. the body of the continuation holds a native monitor
> 2. a native method is on continuation's stack
>  
> Thanks,
> Arek