: Re: Project Loom VirtualThreads hang

[Arnaud Masson]

A long CPU-bound request (without any IO/yield) on a vthread would virtually “pin” its native thread, which is a thing we don’t generally want, no?
(A server can have both CPU-bound and IO-bound requests at the same time.)

That would be a bit like blocking the even loop on NodeJS: https://nodejs.org/en/docs/guides/dont-block-the-event-loop/#blocking-the-event-loop-json-dos (mitigated by the fact there are more than 1 native thread to run vthreads in general).

Wouldn’t vthread preemptive scheduling fix that?
Otherwise, I guess we can insert manually Thread.yield in the slow CPU code but it’s not ideal:

For (int i=0; i<99999999; i++) {
  Thread.yield();
   // CPU-only stuff, or maybe old sync file IO
}

Arnaud



> On 5 Jan 2023, at 19:02, Sam Pullara <spullara at gmail.com> wrote:
>
> So the place where this comes up is when you do a short computation but use tons of threads to do it. Like, for example, I have a brute force embedding search library that uses parallel streams to do the query. If that takes a few seconds (or even hundreds of ms) I still want other threads doing more mundane, fast work to get CPU time rather than every other computation on the system being blocked.

Virtual threads would behave the same way as platform threads in this case. First, there is no time-sharing among parallel stream tasks anyway today, but there is time-sharing between parallel streams and other threads, be they platform or virtual.

Unless otherwise stated above:

Compagnie IBM France
Siège Social : 17, avenue de l'Europe, 92275 Bois-Colombes Cedex
RCS Nanterre 552 118 465
Forme Sociale : S.A.S.
Capital Social : 664 069 390,60 €
SIRET : 552 118 465 03644 - Code NAF 6203Z
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20230106/0588baa5/attachment.htm>