Project Loom presentation at BangaloreJUG

[Nawazish Khan]

Thanks Alan, I initially wanted to use SynchronousQueue. But a
BlockingQueue from the core lib would be ok.

On Fri, Dec 20, 2019 at 6:34 PM Remi Forax <forax at univ-mlv.fr> wrote:

> Using a Blocking Queue or using your own queue ?
>
> Rémi
>
> ----- Mail original -----
> > De: "Nawazish Khan" <md.nawazish.khan at gmail.com>
> > À: "Alan Bateman" <Alan.Bateman at oracle.com>
> > Cc: "loom-dev" <loom-dev at openjdk.java.net>
> > Envoyé: Vendredi 20 Décembre 2019 13:27:19
> > Objet: Re: Project Loom presentation at BangaloreJUG
>
> > Can anybody help me coming up with a contrived example of running a
> > producer-consumer pair in their own virtual threads, but on a *single
> > threaded* executor (schedular). Thanks in advance.
> >
> > Sincerely,
> > MNK
> >
> > On Wed, Dec 18, 2019 at 2:19 PM Alan Bateman <Alan.Bateman at oracle.com>
> > wrote:
> >
> >> On 17/12/2019 22:08, Volkan Yazıcı wrote:
> >> > [To the best of my knowledge,] pinning a carrier thread means that the
> >> > fiber will block the thread. In the current prototype, holding a
> >> > monitor is still a blocking operation.
> >> >
> >> Yes, and here's a simple example:
> >>
> >> synchronized (lock) {
> >>      Socket s = new Socket("pluto.com", 7777);
> >> }
> >>
> >> A virtual thread executing this code will likely park twice when inside
> >> the synchronized block, once to resolve "pluto.com" to a network
> >> address, the second when trying to establish the TCP connection to the
> >> remote host. Virtual threads that park while holding monitors will pin
> >> the underlying carrier thread, this just means it's not available to
> >> help other virtual threads that waiting to continue. It's a limitation
> >> that we want to go away in the medium-to-long term of course.
> >>
> >> The system property for the command line that I included in the other
> >> mail was just a diagnostic option to help track down cases like this.
> >> The output is a stack trace where the frames holding monitors are
> >> highlighted with a count of the number of monitors held. A good
> >> discussion for a meet-ups would be to identify cases like this in your
> >> code and to see how easy it would be replace with j.u.concurrent locks.
> >>
> >> -Alan
>