Native methods and virtual threads

[Robert Engels]

+100

> On Jul 14, 2023, at 3:14 PM, Attila Kelemen <attila.kelemen85 at gmail.com> wrote:
> 
> 
>> 
>> 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.
>> 
> 
> But it is a false dichotomy to choose between not using virtual threads basically at all, and using only VTs. If that is a serious problem, then you could just create a single thread pool for your "slow, blocking native tasks" and then just wait for the submitted task on the VT. It is unlikely to make things very difficult, because you can easily hide this behind a method which is barely different from marking a method as "blocking, please compensate", and you even have more flexibility (which you might need, if you have such an edge case).
>  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20230714/97c7ab03/attachment.htm>