LtU carried an announcement of a paper from Martin Odersky and Phillipp Haller at EPFL called “Event-Based Programming without Inversion of Control”. To quote a snippet:
The central idea is as follows: An actor that waits in a receive statement is not represented by a blocked thread but by a closure that captures the rest of the actors computation. The closure is executed once a message is set to the actor that matches one of the message patterns specified in the receive. The executing closure is “piggy-backed” on the thread of the sender. If the receiving closure terminates, control is returned to the sender as if a procedure returns. If the receiving closure blocks in a second receive, control is returned to the sender by throwing a special exception that unwinds the receiver's call stack.
Scala has had actors in the form of scala.concurrent.Actor since version 1.x, but as extensions of java.lang.Thread they are thread-dependent. Thread-dependent means that a Scala Actor might be preferable to a Java Thread for semantic reasons but that there is no performance advantage. (In fact, a benchmark in the paper shows that it's a disadvantage, but semantics are often more important than raw performance.)
The PXE BPEL engine relies on a little-publicized Java-based actor framework called JaCOb (short for “Java Concurrent Objects”) that makes some different choices than Martin and Phillipp did but that is ultimately based on hooking closures to model the receipt of messages in the future. For a quick tour of JaCOb, there's either the source code or a detailed tutorial written by Matthieu Riou on the Apache Ode incubation wiki.) For one, JaCOb's syntax would be cleaner in Scala, as Java lacks delegates. JaCOb does not use exceptions to break the stack but instead relies on passing communication channels. (Using exceptions for control flow is generally regarded as a bad thing to do. In addition to the philosophical reasons, throwing an exception is involved and, depending on the JVM implementation (e.g., implementing exceptions as signals), can be expensive.) JaCOb doesn't include explicit support for distributed operation as Martin and Phillipp describe for their framework, but a suitable flavor of JaCOb's soup could be implemented.
I'm looking forward to checking out the event-based approach from Martin and Phillipp when it comes out with Scala 2.1.7, and in the meantime, I should finish up the JaCOb tutorial that's been mouldering on my to-do list.
