ActorsAndConcurrency

The Gist

The tour doesn’t touch on this.

My Interpretation

Scala’s concurrency is often touted as one of it’s best/most distinctive features, although it isn’t part of the language, but rather implemented as an API.

While you can certainly use Java Threads in Scala, it is more customary to use the scala.actors package. This package defines classes that interact via message-passing. If you ensure that your messages are immutable (for the most part), you will find it much easier to write concurrent code that works well.

Consider an application that takes user commands and acts on them. Some commands might take a while to complete, but you don’t necessarily want your user to have to wait until they enter the next command.

Naturally, you separate your user interface code from your processing code, and send all requests to the background, allowing the user to continue interacting with the application. This is how the web works and how Swing is supposed to work (if you are kind enough to implement your Actions that way :). When commands are done, you want the user interface to be notified so that the user can have an idea of what’s going on.

In Java, this would be somewhat complex. The Thread interface is very basic, so you’d need to design a “worker thread” class to handle requests and maintain a “user interface thread” to interact with the user. You’d have to provide for a way for the threads to talk. This might be via some shared structure or some shared references to one another.

Here’s the Scala version:

We see that both Actor implementations define the method act and that both basically loop forever around the receive construct. This code is triggered whenever the actor in question receives a message. In the Worker object, we do our work and send the sender of the message a response. sender is an API call in Actor, as is !. The ! is used to send sender a message.

In the first case, we send the sender the Exit object. In the other two cases, we create a new version of Done that indicates which command had completed (we sleep for a second when we get an scp just to make sure things are happening concurrently).

The second class, UserInterface, receives command strings from the caller (in the ActorDemo object), which it sends to Worker, and also handles the responses from Worker, which it uses to inform the user what happened.

The output of this program might look like so:

 Starting ls
Starting rm -rf
Starting scp
ls done
rm -rf done
exiting…
scp foo ssh://www.naildrivin5.com/home/davec/bar done

This is a contrived example, however anyone who has done Swing programming will appreciate the ease with which the work is divided and the communication is organized. This also could be very beneficial in a highly interactive web application; you might send all requests to worker actors, returning a busy indicator immediately to the user. When the worker actor completes, you can update the web application via AJAX, providing for a nice user experience. All without rolling your own message queue infrastructure.

My Thoughts on This Feature

This is the absolute extent to my interaction with this feature, however I did make an attempt to do a Java version. I didn’t get far. This was just so much easier to deal with. Part of it is Scala’s PatternMatching , but I found the actor/messaging/inbox model to be very intuitive and easy to understand.