Native methods and virtual threads

[Holo The Sage Wolf]

> create a single thread pool for your "slow, blocking native tasks" and
then just wait for the submitted task on the VT.

Is it possible currently to make sure that the VT never run on that
designated thread pool?

On weaker systems I can imagine this causing slow downs

On Sat, Jul 15, 2023, 00:13 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/20230715/38e2b8d1/attachment.htm>