I don't want to discourage you from contributing but...
as also descripted in the Loom proposal already suggests - it's much more
than just patching the Instrumenter.
If you want to re-use the threads you also need to add some kind of pooling
and scheduling mechanism.
On Sun, Jan 21, 2018 at 2:00 AM, Cristian Lorenzetto <
cristian.lorenze...@gmail.com> wrote:
> I read now Loom project is thinking to do exactly what i proposed. But when
> it will be available? uhmmm i think i could require years...
> I dont know , maybe i could patch the instrumenter
>
> 2018-01-21 1:21 GMT+01:00 Torsten Curdt <tcu...@vafer.org>:
>
> > This does not remove the restriction on the synchronization - that still
> > exists.
> > The thread could do something else during the wait - but that's another
> > story.
> >
> > There just is not automatic suspend on wait.
> > And it begs the question how such a thing would/should look like.
> >
> > I am not saying this isn't something that could be interesting to
> > investigate - but this is just not what javaflow is.
> > The current javaflow implementation is about state storing and restoring
> -
> > not scheduling and pooling.
> >
> > While you could improve thread usage by implementing thread re-use during
> > wait, the big problem will still always be the synchronized code.
> > So it really feels like you are trying to solve a problem from the wrong
> > end.
> >
> > Anyway - my 2 cents.
> > Take them or leave 'em ;)
> >
> > On Sun, Jan 21, 2018 at 12:36 AM, Cristian Lorenzetto <
> > cristian.lorenze...@gmail.com> wrote:
> >
> > > It is absolutely not true. If a coroutine execute
> > >
> > > synchonized(lock){ lock.wait() }
> > >
> > > the lock.wait blocks the thread. Why i have to block the thread if
> thread
> > > can running other corotuines in the while?
> > > lock.wait must supend the coroutine and resuming another coroutine
> > >
> > > 2018-01-21 0:23 GMT+01:00 Torsten Curdt <tcu...@vafer.org>:
> > >
> > > > I am sorry but I must be missing something here.
> > > >
> > > > The code uses synchronization blocks and mutexes to explicitly make
> > sure
> > > > threads don't interfere which each other.
> > > > This restriction will be there because of resource sharing and the
> java
> > > > memory model.
> > > > Instrumenting wait/notify cannot magically remove that restriction.
> > > >
> > > > Based on queuing theory you can move your bottleneck to your mutexes
> -
> > > but
> > > > that's about it.
> > > >
> > >
> >
>
