> because the stack when is suspended is out from native func.
> instead if i call suspend inside a JNI c++ class the stack is not visible
> from java so probably javaflow dont work.
>
The short answer to that question is "yes".
> I have another different question:
> run(){
> while(!stream.eof()){
> data=read(stream);
> process(data);
> }.
>
> stream is synchonized internally waiting until data is not empty.
>
How is that example even related to javaflow?
What's the goal here?
My question is: normally in synchonized blocks the thread is blocked until
> notify but inside a coroutine the class is instrumented for not blocking
> the thread but just for suspending the coroutine until notify?
>
That doesn't sound quite right.
While it is true that calls to a synchronized function will have to wait
for a lock on "this",
I would not use terms "synchronized" and "blocking" like that.
Maybe let's try give a birds eye view on how javaflow works.
1. On suspend the function will exit but also store state information in
the Continuation object.
2. On resume the library will call the function again, but it will restore
the state and jump to the position after it was suspended.
The synchronization characteristics should not be affected by that.
cheers,
Torsten
