Native methods and virtual threads

[Attila Kelemen]

If we are comparing this to the alternative of the JVM providing
compensation threads for you, then you are creating a double standard here,
because in your custom case now you want to manage multiple different
thread pools, optimizing their sizes and managing them, when in fact the
JVM would not do something for you at all. A fair comparison in my opinion
is that you create a single static thread pool with daemon threads (and a
relatively small thread timeout). Because that is very close to what you
would have with the compensation thread.

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.

Brian S O'Neill <bronee at gmail.com> ezt írta (időpont: 2023. júl. 14., P,
23:50):

> The solution you describe (a single thread pool for blocking native
> tasks) is the same as the message passing solution that I proposed. But
> if I have to manage different thread pools for different type of
> operations, it's no different than using platform threads.
>
> In a world without virtual threads, my server waits on idle sockets by
> using epoll or a SelectableChannel. Tasks can then be dispatched to a
> thread pool. In a world _with_ virtual threads, I don't need to directly
> use epoll or a SelectableChannel. But if I have to dispatch tasks to
> different thread pools, then my server isn't that much different than it
> was before. I'm dispatching to something else all the time, so what have
> I gained? I still have to manage thread pool sizes, etc.
>
> If I'm using virtual threads to dispatch short lived tasks (via
> structured concurrency) I now need to be aware of all of the task
> dependencies. Sometimes I can use virtual threads, and sometimes I need
> to use a regular FJ pool. This is more complex than what I had before,
> when I could just use a single FJ pool and not worry about it.
>
> Am I describing a false dichotomy? No. It's about choosing the right
> type of threads to use, and virtual threads have unfortunate gotchas.
> The safe choice is to design a server to use platform threads by
> default, and later add virtual threads as an option.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20230715/3b33876a/attachment.htm>