[spintin]

https://www.youtube.com/watch?v=WoQJnnMIlFY&t=260s

To get the whole context, so virtual threads are unusable?

What holds a monitor by default and is there a workaround?

Found more:

    A virtual thread cannot be unmounted during blocking operations when it is pinned to its carrier. A virtual thread is pinned in the following situations:

    The virtual thread runs code inside a synchronized block or method

    The virtual thread runs a native method or a foreign function (see Foreign Function and Memory API)

For those those that don't know what this means: Blocking network TCP IO needs a sychronized block to work = you can't use virtual threads for networking. I wish they formulated it like that from the start!

Atleast now we know what they meant with don't use virtual threads for anything but tasks <- not blocking IO with synchronization!

So for now manual NIO is still the king of the hill.

We are reaching peak humanity levels of complexity!

[kaba0]

> For those those that don't know what this means: Blocking network TCP IO needs a sychronized block to work = you can't use virtual threads for networking

That’s not true — blocking TCP IO is not implemented as blocking under the hood - that’s the whole point of virtual threads, so your conclusion is faulty.

[NovaX]

Perhaps it’s better to say that they are not yet general purpose. There are many caveats which need to be resolved and are being actively worked on. I would not use them broadly yet, but that could change rapidly.

A monitor will pin the VT to the carrier thread. That can have surprising incompatibility in the current jdk. Soon these footguns will be fixed and you can use them worry free.

https://www.reddit.com/r/java/comments/1512xuo/virtual_threa...

[spintin]

Well see, if Patricio Chilano hasn't fixed this in a year I would start to get VERY worried.

Moving monitors into Java is not a good solution, like the long solution they are working on.

Java should be the API not the implementation!