tag:blogger.com,1999:blog-19725519.post7660120549919445761..comments2024-02-01T05:22:59.677-05:00Comments on Erik Engbrecht's Blog: Pondering Actor Design TradesErik Engbrechthttp://www.blogger.com/profile/11174963559600768092noreply@blogger.comBlogger14125tag:blogger.com,1999:blog-19725519.post-17024891574510300362009-07-07T10:51:44.080-04:002009-07-07T10:51:44.080-04:00@David,
re: arbitrarily complex message processin...@David,<br />re: arbitrarily complex message processing in LA<br />I didn't miss this, although perhaps I didn't give it it's full due. It's possibly to layer up pretty much anything on top of LA's message processing. That's my point - the user-programmer has to layer it up. As these layers build up, complexity increases. If it's done right, the layering will probably give you something at least as expressive as SA but considerably more robust and tractable. But done wrong you would get spaghetti.<br /><br />re: changing message handling<br />If there's a more elegant way than I showed, which I don't doubt, then please share. I'm sure it could be layered in, but as you layer more stuff in it become much harder to control the complexity.<br /><br />re: futures vs blocking<br />I see different intended semantics here but don't doubt you could translate between the two for equivalent behavior.<br /><br />re: practical matter<br />Yes. This is undoubtedly true, at least for now, and I think a compelling argument could be made that making more complex patterns commonplace would be a step backward. After all, an individual Agha actor isn't even Turing complete. Only a full configuration achieve Turing completeness. But...there are some really neat things SA's model allows you to do. Some of them are seem dubious, but it's hard to ignore their expressive power.Erik Engbrechthttps://www.blogger.com/profile/11174963559600768092noreply@blogger.comtag:blogger.com,1999:blog-19725519.post-62532320327083246112009-07-06T19:19:30.268-04:002009-07-06T19:19:30.268-04:00Erik,
I think you missed a couple of pieces of th...Erik,<br /><br />I think you missed a couple of pieces of the Lift Actor feature set.<br /><br />The messageHandler method can be arbitrarily complex which means that it can perform the same kind of operations that the Scala Actor act method can perform in terms of initialization or "between message" processing.<br /><br />In terms of changing message handling, you gave an example of doing it a very ugly way with LA and a very pretty way with SA. One could very, very easily mix in code to make LA code as pretty as SA code.<br /><br />Lift Actors support blocking the current thread waiting for a Future to be satisfied or for the response from message send.<br /><br />As a practical matter, based on the dozen+ projects I've done with Actors, Lift Actors have all the semantics that I've actually used in production code.David Pollakhttps://www.blogger.com/profile/16630520857988769066noreply@blogger.comtag:blogger.com,1999:blog-19725519.post-70154880333503197042009-07-06T18:30:44.640-04:002009-07-06T18:30:44.640-04:00to blur the lines more, i'm curious how Clojur...to blur the lines more, i'm curious how Clojure's "agents" play out, as well. certainly Clojure suggests people use non-side-effecting, immutable-persistent approaches.Raoul Dukehttps://www.blogger.com/profile/07354740962526930549noreply@blogger.comtag:blogger.com,1999:blog-19725519.post-77859385475596156192009-06-27T11:06:06.665-04:002009-06-27T11:06:06.665-04:00@Runar - Ahhh...I see that now. Thanks.@Runar - Ahhh...I see that now. Thanks.Erik Engbrechthttps://www.blogger.com/profile/11174963559600768092noreply@blogger.comtag:blogger.com,1999:blog-19725519.post-25252299834011226972009-06-26T22:56:31.668-04:002009-06-26T22:56:31.668-04:00The Scalaz actor doesn't hold threads. It dequ...The Scalaz actor doesn't hold threads. It dequeues its mailbox by applying the Strategy to its Effect on messages. The Strategy decides if a thread is held or not.Runarhttps://www.blogger.com/profile/14764166579276982834noreply@blogger.comtag:blogger.com,1999:blog-19725519.post-90447597876986115972009-06-23T08:35:29.394-04:002009-06-23T08:35:29.394-04:00Tony,
There's also an AtomicBoolean hiding in...Tony,<br /> There's also an AtomicBoolean hiding in there. I was wondering how it kept track of its suspended-or-not state. I think mailbox+suspended-or-not represents the absolute minimal amount of mutability.<br /><br />I can't say that I 100% grok Scala Actor, but it looks to me like it holds a thread as long as it has messages to process in its mailbox. Given thread pool with a max size and a lot of very busy actors, this can lead to starvation problems because the busy actors never let go of their threads. The starvation problems can then lead to deadlock.Erik Engbrechthttps://www.blogger.com/profile/11174963559600768092noreply@blogger.comtag:blogger.com,1999:blog-19725519.post-76675491931638379322009-06-23T07:20:55.164-04:002009-06-23T07:20:55.164-04:00Tony,
Good point, and I agree 100% with the sen...Tony, <br /> Good point, and I agree 100% with the sentiment. Put I'll point out that the Scalaz actor implementation does indeed contain a minimal amount of mutable state.<br />http://code.google.com/p/scalaz/source/browse/trunk/src/main/scala/scalaz/concurrent/Actor.scala<br /><br />You see a ConcurrentLinkedQueue in there, which is used for the mailbox, which is mutable. You can't get away from having at least a small amount of mutable state.<br /><br />For reference:<br />http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/ConcurrentLinkedQueue.htmlErik Engbrechthttps://www.blogger.com/profile/11174963559600768092noreply@blogger.comtag:blogger.com,1999:blog-19725519.post-58351605249269540112009-06-23T03:46:13.713-04:002009-06-23T03:46:13.713-04:00The problem with Scala's actors can be summed ...The problem with Scala's actors can be summed up pretty quickly: "default mutability with endless attempts to tack on immutability". This inflexibility provides no benefit.<br /><br />Functional Java and Scalaz do it the other (right) way around.Tony Morrishttps://www.blogger.com/profile/17206456907461293947noreply@blogger.comtag:blogger.com,1999:blog-19725519.post-55376719203587158362009-06-23T02:34:03.370-04:002009-06-23T02:34:03.370-04:00Dan,
You may find the following useful
http://ww...Dan,<br /><br />You may find the following useful<br /><br />http://www.javaworld.com/javaworld/jw-03-2009/jw-03-actor-concurrency2.htmlMhttps://www.blogger.com/profile/14472275833277577640noreply@blogger.comtag:blogger.com,1999:blog-19725519.post-45479208305564952562009-06-22T20:53:42.141-04:002009-06-22T20:53:42.141-04:00Hi, I stumbled across this blog and enjoyed readin...Hi, I stumbled across this blog and enjoyed reading the post. Would it be possible to get names or links to the various actor implementations?Dan Chamberlainhttps://www.blogger.com/profile/15602542579173074596noreply@blogger.comtag:blogger.com,1999:blog-19725519.post-64976004281802660372009-06-22T09:58:36.710-04:002009-06-22T09:58:36.710-04:00One thing I would like to see is a general purpose...One thing I would like to see is a general purpose benchmark that could be applied across the various actors library implementations. Right now I see blog entries pop up with claims about performance and it's difficult to compare them. I'm sure some tests (like ping pong) could be used as a starting point, although it would be important over the long run to build out a more comprehensive test suite.<br /><br />Thanks for the write-up<br />PatrickPatrick Wrightnoreply@blogger.comtag:blogger.com,1999:blog-19725519.post-44732020457086120052009-06-22T09:54:04.930-04:002009-06-22T09:54:04.930-04:00Great post.
Exactly the trade offs I did when I c...Great post. <br />Exactly the trade offs I did when I created my own actors library. Trading expressiveness over configuration and speed. <br />/JonasJonashttp://jonasboner.comnoreply@blogger.comtag:blogger.com,1999:blog-19725519.post-59253248217058068032009-06-22T07:45:40.783-04:002009-06-22T07:45:40.783-04:00I've been following your state-based rewrite, ...I've been following your state-based rewrite, but haven't been following as closely since the last big series of discussions about actor implementations on the mailing lists.<br /><br />I think a SID would be a good idea, if only to bring a more centralized debate to the design discussions happening in various places. You and others have made a lot of salient points towards various designs, but it's hard to summarize all the various points across various threads and lists without having made some of the points.<br /><br />Furthermore, I'm interested in the design choices which enable various analyses on actor usages (for example, to statically approximate deadlock or stuck-freedom). Your post here is a good starting point for me to investigate further. Keep on posting!Nobodyhttps://www.blogger.com/profile/13128758853001011657noreply@blogger.comtag:blogger.com,1999:blog-19725519.post-64148179046829666172009-06-21T21:57:24.728-04:002009-06-21T21:57:24.728-04:00this is a fantastic start and i see no reason why ...this is a fantastic start and i see no reason why it couldn't get to be a SID. great post.Anonymousnoreply@blogger.com