Steven Parkes : smparkes.net

The first alpha release of dramatis hit the streets today.

dramatis is a library available in Ruby and Python used to write concurrent programs based on the actor model of concurrency.

The release, labeled 0.1.1 (0.1 for first alpha, patch level 1 since the first release artifacts were a bit bollixed up), is available on rubyforge and pypi, as well as the git repository.

This release supports both Ruby and Python and comes with documentation, including API docs, several examples, and a tutorial.

The Python docs are, admittedly, a bit squirrely. The code has docstrings in it but the docstrings have not been pulled out into HTML. After looking at pydoc, epydoc, happydoc, and doxygen, it’s still not clear to me the best approach to Python API docs. I’d appreciate suggestions and recommendations.

It’s still early in dramatis’ life. It’s useful in its current state for writing data-driven/data-flow kinds of code and for concurrent I/O. It should be truly concurrent in JRuby but the last JRuby snapshot I tested (which was a while ago) had some weird dynamics when threads were involved. Need to test that again.

The two things I’d like to expand first are:

- Added actor-to-thread-pool binding so non-thread-safe code like GUI toolkits can be integrated

- Interprocess communication via XMPP

but the list of things that would be fun (and useful) to implement is long …

Comments are welcome here or on the the google group.

It’s an interesting time for actor concurrency. I try to follow the related discussions on the Erlang and Scala mailing lists and the rubinius IRC channel. Not to mention the stuff that happens at large, things like Ezra’s talk about Vertebra. (Hmmm … other people have talked about actors; Ezra seems to use agent; I thought I saw him write actors, but I don’t see it now).

Wonder if it’s time to have a place for language/library-agnostic actor discussions?

Charlie Nutter gives a good roundup of Ruby implementations past to present, with a few guesses as to the future.

I’ve played with four: 1.8/MRI, 1.9/YARV, JRuby, and Rubinius. What I found a bit surprising is that I’ve come to appreciate pieces of all of them. MRI is pretty stable and widespread. 1.9 allows me to play with OS threads faster. JRuby allows me to play with the JVM crowd (and push threads even more). And I think we all owe the Rubinius for the spec work.

But there’s one thing that having four versions has helped immensely with: writing Ruby with threads. Threads can be such a bloody pain to develop. In all but the simplest programs, it gets pretty tough pretty quickly to be sure there are no unexpected sequences of events. When you run primarily on one platform/library, you pretty quickly surface the low hanging fruit: the races/sequences that occur most frequently on that platform. But there are all those rarer cases that kill you. Since they’re rare, they’re typically gone by the time you notice them and it’s virtually impossible to get them to repeat. So you start to rationalize: maybe I didn’t really see it; maybe I misinterpreted what I saw. Maybe it was a side effect of something else I already fixed.

But in the back of your mind, you wonder if you’re lying to yourself.

It’s the stuff of nightmares, a monster you just know is hiding under your bed.

In the case of Ruby, we have four implementations that share a pretty solid thread model … with wildly varying dynamics. In developing some threaded code, I started on MRI and made it solid. And then ran on 1.9 and everything went to hell because things were happening in a different order. Ditto for JRuby. So far, the only case where I didn’t surface more corner cases was Rubinius, which either means I’m getting farther out on the latent bug curve or I simply haven’t run enough tests on it.

If you’re writing threaded code on Ruby and it’s feasible, it might be worth considering developing on more than one VM, even if you only expect to actually roll one VM into production.

Of course, avoiding writing-down-and-dirty with threads is not the only nor (arguably) the best approach to concurrency, but you already knew that …