• Intel
  • Microsoft
  • Google
  • Sun Microsystems
  • BT
  • IBM
  • Yahoo! Inc.
  • Zimbra
  • Atlassian Software Systems
  • Disney
  • EnterpriseDB
  • Etelos
  • Ingres
  • JasperSoft
  • Kablink
  • Linagora
  • MindTouch
  • Mozilla Corporation
  • Novell, Inc.
  • Open Invention Network
  • OpSource
  • RightScale
  • Silicon Mechanics
  • Tenth Planet
  • Ticketmaster
  • Voiceroute
  • White Oak Technologies, Inc.
  • XAware
  • ZDNet

Sponsorship Opportunities

For information on exhibition and sponsorship opportunities at the conference, contact Sharon Cordesse at scordesse@oreilly.com.

Media Partner Opportunities

Download the Media & Promotional Partner Brochure (PDF) for more information on trade opportunities with O'Reilly conferences, or contact mediapartners@oreilly.com.

Press and Media

For media-related inquiries, contact Maureen Jennings at maureen@oreilly.com.

OSCON Newsletter

To stay abreast of conference news and to receive email notification when registration opens, please sign up for the OSCON newsletter (login required).

Contact Us

View a complete list of OSCON 2008 Contacts

An Introduction to Actors for Performance, Scalability, and Resilience

Programming, Tutorial
Location: D139/140 Level: Novice
Average rating: ***..
(3.33, 3 ratings)

In 2007, perfect storm conditions developed to launch the entry of actors into the mainstream of concurrent computing (and more and more concurrent computing is becoming the mainstream of computing):

  1. The book Programming Erlang was released, giving everyone an easy yet in-depth introduction into Erlang, by far the most mature actor-based open (or closed) source system available.
  2. Everybody and their brother (well, the alpha geeks) began to “play with the big boys” and run ejabberd, the Erlang Jabber server (almost certainly the most significant Erlang software outside Erikson). This was motivated, perhaps, in part for the fun of running their own IM server but more and more it is being used as an XMPP platform for a wide variety of notifcational purposes.
  3. The number of cores in machines really began to take off: quad-core desktop machines are now becoming common place.

People began to hear of Erlang, see its success at Erickson and in ejabberd, and became interested in its concurrency model, actors. Because Erlang is a functional language, some have assumed actors was a programming model for functional languages.

In this tutorial, we present actors using two programming languages and models. We present actors in Erlang, a functional language, and using Dramatis, an actor library for imperative dynamically typed languages like Ruby and Python (the tutorial will (likely) use Ruby). We show how the actor model can be used to enable concurrency in applications without having to program with explicit thread libraries, avoiding many of the complexities of that model. The goal is to show the breadth of what can be done with actors. Since actors make concurrency easier but maybe not easy, areas in actors where things can go wrong are also covered.

The tutorial is hands-on throughout, for attendees that wish to follow at that level. It uses an example application and starts with the basics of creating actors and making calls between them. It shows how actors call methods on each other and what happens if those calls fail. It shows how sets of actors can cooperate to detect and recover from internal and external failures.

At the end of the tutorial, attendees should be able to extend the Erlang or Dramatis demo application to add functionality or to adopt another actor library and begin to work with it. They should also be prepraed to start to apply actors to their own needs, for example, to begin to parallelize a compute-intensive program for multiple cores or to use to develop and infrastructure for communicating information between systems running on different hosts.

Outline (assuming a couple of breaks)

Part I: The basics (60 minutes)

  • The example: a simple IRC server (demo in Erlang and Ruby)
  • Actor objects
  • Actor calls: sending messages
  • Blocking? Non-blocking? Kinda blocking?
  • Exceptions
  • An aside: Why do we need it? Why is concurrency hard?
  • Comparison to Thread model
  • Actor gotchas

Part II: Behind the curtain (60 minutes)

  • Actor names
  • Actor mailboxes
  • Distributing actors
  • Advanced exception handling
  • The development environment

Part III: Extensions and Evolution (40 minutes)

  • Actor runtime/container services
  • Runtime isolation for resiliency and privilege
  • Actor placement
  • Actor call ordering


Steven Parkes

smparkes.net llc

Steven Parkes is an independent software developer in Palo Alto, California. He has been involved in concurrent object oriented programming for many years (his graduate thesis was on an Actor library in C++) . He currently specializes in high-reliability design for backend systems.

OSCON 2008