[External] : Re: Native interop with Virtual Threads

[Andrew Haley]

On 6/27/23 00:01, Ron Pressler wrote:
 >
 >> On 26 Jun 2023, at 17:45, Danish Nawab <dnawab at outlook.com> wrote:

 >> What would be the advice if someone is making blocking calls from
 >> their downcalls? It might not always be possible to rewrite it in
 >> Java.
 >
 > If those operations are both frequent and lengthy, they shouldn’t be
 > done on virtual threads.

I don't understand why this is even an issue. If the Java code calls
native code which blocks or calls back into Java code, then we'll need
a platform thread. We can't know what the native code does, and the
native code owns the platform thread for the duration. So that
platform thread has to exist, and we need one for each native blocking
call.

But the Java code required to do this is mot much more than:

     ExecutorService ex = Executors.newCachedThreadPool();

     public <T> T submit(Supplier<T> aSupplier)
             throws ExecutionException, InterruptedException {
         if (Thread.currentThread().isVirtual()) {
             return ex.submit(aSupplier::get).get();
         } else {
             return aSupplier.get();
         }
     }

I suppose we could provide a standard method which does this, but it's
not much of a big deal. But it probably makes more sense to leave this
to user code because then the user gets to decide policies for
timeouts, the size of the pool to use, etc.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671