[External] : Re: : Re: Project Loom VirtualThreads hang

[Ron Pressler]

On 6 Jan 2023, at 16:37, Robert Engels <rengels at ix.netcom.com<mailto:rengels at ix.netcom.com>> wrote:

I have to agree a bit with Arnaud. I don’t like the idea that I have to “reason about” these issues.

I’m not asking anyone to reason about any issue. I am asking people to report any problem they run into, as that is extremely valuable feedback and could help us a lot.

Reporting a hypothetical problem that people have *not* run into is not particularly useful, not because the problem cannot manifest in reality, but because I don’t know how to solve a hypothetical problem (how would I know that I’ve solved it)? There’s just nothing we can do with that discussion (and these are all things we’ve thought about for years, but because we haven’t been able to observe them, we obviously haven’t been able to address them).

I just don’t know how to fix a non-bug. We could add, say, a 10ms time slice, but would that really fix a problem that we haven’t seen yet? How would we know that the non-bug has been fixed before if no one encounters the bug?

Imagine a server service that encodes video. Highly cpu bound. But then a need to emit heartbeats to keep clients alive. I have to know “put heartbeat requests on their own native thread” because too many client encoding requests will cause them not to be sent. Or even more simply - a very short encoding request takes a very long time because it is blocked by other long running requests that got there first. FIFO doesn’t lead to the best user experience at times.

With timeslicing and fairness that can be avoided.


Yes, but there’s a much better way to do this than by adding timesharing to virtual threads: run your encoding service on platform threads.

— Ron

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20230106/b7c36fbf/attachment.htm>