commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cristian Lorenzetto <>
Subject Re: [javaflow] - how to use continuation in JNI boundary
Date Sat, 20 Jan 2018 20:53:22 GMT
this is a problem for me.

My idea is to use many coroutines instead to use many threads because it is
more scalable.
Consider i realize a scheduler in which i can push many coroutines.
Pratically it is a coroutines pool inside the same thread.

When a corotuines is blocked by a wait() instruction it is not necessary to
block the thread but it is sufficient to suspend it.
When a corotuine is suspended , it is taken another  coroutine ready to be
resumed. In this way the thread is never blocked ... and the global
performance will be very hight.

For this reason is important to instrument synchronized blocks.

2018-01-20 19:51 GMT+01:00 Torsten Curdt <>:

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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message