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