> On Jul 1, 2017, at 1:51 PM, Rodric Rabbah <[email protected]> wrote: > > >> it is quite common, for example to run nodejs applications that happily >> serve hundreds or thousands of concurrent users, > > I can see opportunities for treating certain actions as intrinsic for which > this kind of gain can be realized. Specifically actions which are performing > network operations then computing on the result. One can split the > asynchronous io, and pack it into a more granular concurrency engine. > Intuitively, I think it's more likely to benefit this way and protect against > concurrency bugs and the like but using higher level action primitives. > > -r
I’m not sure what you’re getting at - are you suggesting splitting the network operations out and running them “not as actions” or “separate from compute portion of the action"? I’m sure that would be possible, but it would seem like diminished returns in complexity for 90% of cases where “computing on the result” is lightweight compared to the waiting for IO completion, I’m not sure it would be worth it to force developers down a path of configuring actions based on the network ops of the code within, compared to simply allowing concurrency. Thanks Tyson
