<div dir="ltr"><div>Hello Ron,</div><div><br></div><div>Quoting:<br>
<pre>"Virtual threads replace <b>short </b>individual *tasks* in your application, not platform threads."<br><br></pre><pre> Why <b>short?<br><br></b></pre><pre><b>Take a TCP server's accept loop.  I would have thought that's a natural target for execution in a virtual thread. <br><br></b></pre><pre><b>And it's more or less intended to run forever.<br></b></pre><pre><b>
"They are best thought of as a business logic entity representing a task rather than an “execution resource.”"<br><br></b></pre><pre><b>That's a pretty good definition of an "actor" (as in actors-model).  But there's no (even implicit) restriction on the duration of <br></b></pre><pre><b>an actor's lifetime.<br></b></pre><pre><b>Is it your intent to proscribe virtual threads as a possible implementation for actor-model type designs?  <br></b></pre><pre><b>I'm thinking of simulations, e.g. modelling a migrating herd, bees at a honeycomb, a very busy traffic intersection, et al.<br></b></pre><pre><b>It seems natural (even elegant) to represent each of those entities (deer, bee, car) as a virtual thread, and executing them as a <br></b></pre><pre><b>platform thread isn't an option (because of their sheer number, the essence of the problem that virtual threads is the solution for)<br></b></pre><pre><b>And I'm sure there are innumerable other circumstances that could benefit from LWP (as Erlang terms them)<br></b></pre><pre><b>IMO, it's awfully reductive to restrict practical uses of virtual threads to writing sequential single request/response scenarios 

<br></b></pre><pre><b><br></b></pre><pre><br><br><br><br></pre>

</div></div>