Native methods and virtual threads

[Brian S O'Neill]

How would a call like `NativeUtils.runBlocking(() -> mytask())` be 
implemented? By using a thread pool / message queue / FJ pool? In doing 
so, I've introduced a context switch. If the native method didn't 
actually block, then I just added a context switch for no good reason.

Internally, the JDK uses a special Blocker class to handle this case. 
The nice thing is that it doesn't introduce an extra context switch or 
heap allocation.

The whole point of this entire message thread is to ask for a simple 
feature in which native threads can indirectly utilize this special 
class (or whatever is best suited) and keep things simple. As virtual 
thread support evolves over time, I don't need to change my code.

On 2023-07-14 03:14 PM, Attila Kelemen wrote:

> 
> As for " Sometimes I can use virtual threads, and sometimes I need to 
> use a regular FJ pool": It wouldn't be like that, because only the 
> operation which is slow and pinning (and not compensated) should be just 
> written like this: `NativeUtils.runBlocking(() -> mytask())`, instead of 
> just writing `mytask()`. It would never be a choice between do I start a 
> VT or submit it to a thread pool? And presumably this is not the 
> majority of your code. And that is what you would gain, that you still 
> are mostly using VT, only those special pinning methods are not.
>