Project Loom presentation at BangaloreJUG

[Remi Forax]

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