[External] : Re: Project Loom VirtualThreads hang

[Ron Pressler]

> On 5 Jan 2023, at 00:25, thurston N <thurston.nomagicsoftware at gmail.com> wrote:
> 
> " With virtual threads available, you can use that style no matter what the load on your server is, and easily switch between thread implementation if it makes a difference."
> 
> Can you? 
> even if it's a configuration option, you need to bounce a production server(s) to "switch"
> 
> My experience jibes with Robin's, especially since load is not constant in the real world, as long as virtual threads offer acceptable throughput and latency *even when their true benefits, viz high numbers are not in effect".  If that is the case (and I don't see why it wouldn't be), the question might better be "why would you ever bother to switch (from virtual to platform)"? 

If the workload *could* rise to the point that it requires more threads, then virtual threads already help: they support the possibly-needed scale, and if they work well at some high throughput X, then they obviously work well at throughput 0.1X. There’s obviously no need to switch.

I’m talking about cases where the workload is such that it could never rise to the point where virtual threads would be necessary, and the appropriate thread implementation is picked during development, but whatever it is, the thread-per-request style that the platform is designed for would fit well. So you can always use the right style for Java, no matter what your workload is, and then you can pick an appropriate thread implementation for your application. In the vast majority of cases, the choice in the low-throughput cases doesn’t matter much, but when it does, it’s not an API choice, but a simple implementation choice. So in these cases there’s also no need to switch.

My main point is to try and steer the discussion away from cases where, for whatever reason, the developer doesn’t wish to use the thread-per-request model, because however well virtual threads perform such tasks now, that is not their primary focus. Once the ecosystem gains more experience with virtual threads for their primary usage, we can shift our attention to other uses as well. There’s a lot of excitement about virtual threads, and people are experimenting with them for various tasks — and that’s great. But because we must choose what to focus on *first*, we choose the more common use-cases where the performance impact is also much higher (and if virtual threads help for other things too, that’s terrific, but still not our primary focus).

— Ron