Scala-Exchange - Concurrency is a Big Deal in Scala

[Rick Beton <rick.beton@xxxxxxxxx>]

Hi all,

I went to the Scala Exchange in London this week. Concurrency is a big deal in Scala. The received wisdom is that everything has to be non-blocking because threads are a scarce resource. This is often justifiable, occasionally not (example case history).

I decided to write some thoughts up why on this and why it's unfortunate in my latest blog. It's interesting to contrast Go, which is at ease with concurrency and enthusiastically advocates it, against Scala, where it is seen as something of an expert topic.

I'm also interested in Akka, which is now (from v2.10) the standard Scala actor library. In particular, it appears to offer a subset of CSP - each actor is like a CSProcess containing a while(true) loop; each process has only one input channel, which is always a shared channel with infinite buffering. The channel doesn't have any identity outside of its actor; clients write to the channel, but use the name of the actor to do so.

So I have a question: would it be possible for a pluggable bundle of input channels on Akka actors so that the model would become more general? (The default behaviour would remain the single Any2One channel with infinite buffering.)Â It would be necessary to introduce Alternative and the other types of channel currently available in JCSP (for example), and this shouldn't itself be too hard.

But Akka also provides remoting, therefore it would be necessary for the channels to automatically pick up their networked configuration via existing Akka techniques.

I'm no expert on Akka so this is a bit outside my comfort zone. Anyone care to enlighten me further?

Rick