I’m attending tonight a presentation on actors and actors in scala, presented by SDForum Software Architecture SIG. Upcoming meeting: July 21, 3rd tuesday, Vijay Patel linked in talk about analytics. Carl Hewitt, Stanford; Robey Pointer, Twitter; Frank Sommers, Artima; Bill Venners moderating. Abstract to concrete.

I’ll post this as-is and come back and edit it later.

Carl Hewitt, Stanford, inventor of actor paradigm

Carl Hewitt: back in the day in 1972 we programmed Smalltalk with a magnetized needle and a steady hand, uphill in the snow both ways.

Three things: send more messages; create new addresses; decide what state for next message. Petri nets as a model suffer from being physically impossible. The three way model has the advantage of being possible. Implications of actors model breaks representation as turing machine or in lambda calculus.

Cloud: it’s clients, all the way up. (Title for client server interaction on the cloud: the fog rolls in.) John MacCarthy defines lisp in terms of lisp. “How many have seen ‘eval’?” 2 hands. Review of that lecture from 61a. Instead of eval the function, eval as a message. If I’m X and I get an eval message with an environment. This is the best way to define concurrent programming languages currently. Bah, say mathematicians, that’s circular! Well, too bad, concurrency doesn’t fit math.

Define theoretical PL ActorScript. XML and JSON instantiations. No assignments, but not functional. Actors get replaced by their next version.

Tension between well-targetted ads and user desire for privacy. But government can’t mine your data fast enough. Spooks will need to reside inside datacenters. Try to move behavioral targetting to client, store encrypted data on cloud. July 23rd symposium on semantic integration at Stanford. Info at http://carlhewitt.info

Invented the one minute lecture. Advertisers can deliver a coherent lecture in 30 seconds. (Fantastic idea – I should do this) Lots of questions following his lecture. This guy just drops the bomb in terms of many ideas at once. Stalinist theory of computation. Lots of parrallelism down the tree. Company model of computation. Different departments. All of the departments talk to each other without having to go through the CEO. That’s concurrency. Map Reduce does the parrallelism but doesn’t do the concurrency.

Frank Sommers - Actors in Scala

Why scala makes actors natural. Example Scaling actors the future

Immutability, OO + functional, pattern matching, easy DSL, JVM. Mainstream language that lends itself to Actors.

Walks through use of Scala actors showing a chat program. When user joins, receiver of subscribe message create a new actor to handle updating the user. Illustrates the shorthand syntax for actors. Sync, async and futures messages. Gets derailed by questions from audience that are too detailed.

Scala actors support working in a distributed fashion, same syntax as within a single VM. Need to import RemoteActor._, listen on a port. Sending actor needs to know the “node”, tuple of address, port number, and symbol. Thread-per-actor and Event-driven actor implementations. Example used thread-per-actor, but better scalability with event driven actors, execute actors on a thread pool. Wait for messages without consuming a thread. Can scale to millions of actors on a single JVM using this system. Able to schedule actor sending message to another actor within the same thread, effectively performance of subroutine call.

Missed a bit, I think he’s talking about how react cannot return conventionally. But now the time is displayed in my emacs status bar, so all is good. Now I just need to display my battery status.

Will be getting continuations in the future. Pluggable schedulers, better actor isolation using compiler plugin, static checking, integrating exceptions, actor migration (to different node? I assume). Tensions whether actors should be more complicated, or if the actors library should remain very basic. Also question of single actors library or multiple actors libraries, e.g., Lift uses a simpler library than Scala actors. Partially pragmatic concerns versus more pure approach.

Still lots of theoretical problems, but quite usable for any actual scenario.

Robey Pointer – Twitter

Talk is titled “solving problems with actors”. Got started with Actors writing a chat proxy for cell phones. Long lived connections, lots of connections, mostly idle. First attempt was with one thread per session. Very simple, but didn’t scale. Went with thread pools and async IO. More scalable but harder to read. Fatal flaw: blocking on other services (http). Fix all APIs to be async using hideous callbacks. If it doesn’t fit on a slide, it’s not good code.

Actors: each session is an actor. Events are just messages. Can seek ahead for specific events. Works will with java.nio and apache mina. Mina wraps nio as events, his naggati library translates this into scala messages.

Kestrel. Message queue. Memcache protocol as a Mina plugin. Scales horizontally, no awareness of each other. Stats on one server: 1 month uptime, 2.4 TB written, 4 billion gets, 1.6 billion sets.

Actors just one of many tools. Used synchronized for some features. What didn’t work: each queue is an actor. Move to queues using synchronized data. Need to read this code and study it.

Actors are still a little shaky. Actors lifetime issues. Mixing threads with actors make it hard to GC.

Lots of exciting stuff.