Native methods and virtual threads

[Brian S O'Neill]

That's a very bold claim. Every native library I've written or had to 
interact with has performed blocking at some level, whether it be file 
I/O, network I/O, or mutexes. Many popular embedded databases are in 
fact not written in Java, and the native calls can block. JDBC drivers 
which rely on native code also block.

If the official statement is to not address the problem, then I'm close 
to reaching the conclusion that virtual threads might have been a 
mistake. It adds complexity to the Java platform, and native methods now 
have to ask the question, "what color is my thread?"

If I'm writing a new service, and I have complete control over what 
native libraries it depends on, I might conclude that virtual threads 
are a good choice. But as the service evolves, I might want to start 
depending on native libraries that provide needed functionality. If they 
perform blocking operations, I might need to wrap the library with a 
message passing queue, which just adds overhead and complexity. If the 
advice is to stop using virtual threads at this point, I could have made 
that decision from day one. And it seems that's the safest option.


On 2023-07-14 01:09 PM, Ron Pressler wrote:
> Because blocking native calls in Java are not very common (at least outside of the JDK itself) and because using platform threads in Java is easy we have no short-term plan for making very frequent blocking native calls work in perfect harmony with virtual threads in general, nor are we aware of a pressing need for that. When we find significant demand for code that uses blocking native calls extensively and yet still gains significant benefit from the use of virtual threads, we will adjust the matter's priority accordingly.
>