Project Loom VirtualThreads hang

thurston N thurston.nomagicsoftware at gmail.com
Tue Jan 3 19:24:18 UTC 2023


Hello Ron,

Quoting:

"Virtual threads replace *short *individual *tasks* in your
application, not platform threads."

 Why

*short?*



*Take a TCP server's accept loop.  I would have thought that's a
natural target for execution in a virtual thread. *


*And it's more or less intended to run forever.*



*
"They are best thought of as a business logic entity representing a
task rather than an “execution resource.”"*


*That's a pretty good definition of an "actor" (as in actors-model).
But there's no (even implicit) restriction on the duration of *


*an actor's lifetime.*


*Is it your intent to proscribe virtual threads as a possible
implementation for actor-model type designs?  *


*I'm thinking of simulations, e.g. modelling a migrating herd, bees at
a honeycomb, a very busy traffic intersection, et al.*


*It seems natural (even elegant) to represent each of those entities
(deer, bee, car) as a virtual thread, and executing them as a *


*platform thread isn't an option (because of their sheer number, the
essence of the problem that virtual threads is the solution for)*


*And I'm sure there are innumerable other circumstances that could
benefit from LWP (as Erlang terms them)*


*IMO, it's awfully reductive to restrict practical uses of virtual
threads to writing sequential single request/response scenarios

*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20230103/4d429d89/attachment.htm>


More information about the loom-dev mailing list