Your article of 2010 May shows you reinventing actors-model queues within actors-model to perform what should be trivial composition tasks in a reasonable programming model. If that isn't already ankle-deep in a Turing tarpit, what is it? a Turing peat bog? How much will these intermediate queues affect latency?
The issues with composing actors arise because local concurrency and consistency properties for handling even one lone message aren't maintained by default across composition. Complexity and Turing-tarpit issues explode further when one starts considering (a) multi-message protocols, (b) shared service or shared resource actors of a large group of independent client actors, (c) client-actors coordinating with multiple independent service-actors - and especially various combinations of two or more of a,b,c. While distributed programming and automated code distribution is where my heart lies, these actors model issues arise even for local computation. I'll grant that actors probably seems a big step up from direct manipulation of shared state, and it certainly avoids simple state-consistency issues for two-party interactions. Actors model does an effective job of pushing issues to a coarser 'message' granularity for atomic actions, alleviating some developer pain. But all the same shared-state and consistency issues remain at the coarser granularity - regardless of your mind remaining focused on in-the-small "protocol and behavior". Anyhow, I'll continue to peruse your articles via the PiLuD releases. I certainly won't deny that you'll learn and understand a great deal about the models you implement in actors. (Of course, the same could be said regardless of the implementation paradigm.) David On Sat, Jun 19, 2010 at 7:54 PM, Dale Schumacher <[email protected]> wrote: > Hi David, > > I've actually read quite a bit of your actor-related material and I'm > aware of your criticisms. I respect the fact that your opinion has > grown out of experience, rather than just thought-experiments. > However, my own experimentation has led me to different conclusions. > > To be clear, the context of my exploration has been what I call > actors-in-the-small rather than actors-in-the-large. While the issues > of multi-core shared-memory-multiprocessing significantly overlap the > issues of open distributed systems, certain problems (like message > loss) are less important, and other problems (like latency) are more > important for actors-in-the-small. > > When I say that the actor model is flexible enough to model the > mechanisms of other computational models, I _do not_ mean simply in > the "Turing tar-pit" sense. For me, the actor model places the > emphasis on message protocols and behavior, rather than mutable state > and global consistency. In that sense, I find that describing other > computational models with actors helps me to understand the event > interactions that are hidden within the primitives of each model. > This leads me to a better understand of how each mechanism works, and > provides a basis for comparison between models. I will be publishing > further articles illustrating exactly what I mean by this. > > Thanks for your thoughtful response. I look forward to continued > productive debate on these fascinating subjects. > > Dale > > -- > send mail : [email protected] > subscribe : [email protected] > unsubscribe : [email protected] > home page : http://groups.google.com/group/pilud > Note: reply address is set to the list -- no need to "reply all" > _______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
