Steven Parkes : smparkes.net

Interesting discussion about actors “with threads” and actors “without threads” here.

In the actor model, abstractly every actor has a thread. When not actually executing a method/responding to a message, i.e., most of the time, that abstract thread is blocked, waiting for a message.

These abstract threads may or may not be actually implemented with a real (read dedicated) thread. A thread will always be required to actually respond to a message/execute a method, but beyond that, there’s a bit more freedom in implementation.

The thread-per-actor approach generally raises issues of resources, and to a lesser extent, context switching. The weight of a thread varies from system to system, but with the exception of custom VMs, e.g., Erlang, threads are often resource intensive. Among other things, they need independent stacks.

On the other hand, in a thread-per-task (where a task represents a message sent to an actor/a method call on an actor), a pool of threads can be kept around and shared among actors as tasks are created. This makes the resource requirements for inactive actors much less.

All this makes it sound like task threads rather than actor threads are the way to go. However, there’s a gotcha: there’s a certain amount of state that needs to be maintained between messages. In actor systems with an explicit receive like Erlang, most if not all of the actor’s state is maintained on the stack. Since threads are usually how stack state is maintained, you generally need a dedicated thread.

Dramatis, however, is a bit more like Erlang/OTP gen_server than it is straight Erlang: the receive in dramatis is implicit, much as it is in Erlang/OTP’s gen_server. This has the side effect that there’s no stack state that needs to be maintained between receives. In these cases, in dramatis a thread isn’t dedicated to the actor. There are cases, however (rpc-like blocking calls, much like gen_server:call), where receipt of the response from the callee needs to continue where it left off in the caller: in those cases, dramatis does dedicate a thread, for the duration of that message exchange. Seems like a reasonable tradeoff, but it will depend a lot on the frequency of different styles of communication and at this point, we don’t have enough experience to know how that will fall out.

Seen lots of stuff on this lately, in Scala and in Kilim. Interesting times.

On a related subject, I setup a google group, actor-talk, that might be useful for this kind of “non-denominational” discussion about actors, that is, across language and library implementations. Seems to me it’s a small enough community at this point that it would be nice to learn from each others’ experiences, strengths, and weaknesses.

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?

Tim Bray: My experience in the Wide Finder didn’t particularly make an Erlang-lover, but I sure did come to appreciate its message-interchange framework.

So is this going to be the year of message passing? I’m old enough to remember many years that were going to be the “year of LAN”. For years, people that used LANs couldn’t figure out how people that didn’t have them could do without. Then LANs broke out and everybody did have them. And before long, nobody could figure out how they could do without. But it was years.

Will that happen with concurrent programing, and with message passing based concurrency in particular? Or will it always be a niche for the somewhat crazy?

It does seem like once you start, it’s a bit hard to image going back. You might not need to go hog wild and create a telco switch with tens of thousands of processes every day but once you have easy concurrency, you find lots of little uses for it, where you had rather annoying non-concurrent code in the past.

That is, that’s true for some definition of easy concurrency. There’s the rub. How much harder does writing concurrent programs have to be? Can we make it not harder at all? Or only a little harder? Because if we can’t, I doubt it ever will break out. That despite the dreams of all the multicore CPU vendors.

I’m optimistic, but there are a lot of degrees of freedom when it comes to deciding how to implement concurrency, even in message passing systems. So it seems unlikely that the same “right” approach is going to be obvious to everyone. I don’t how this will evolve, just the thought that the paradox of choice (not to mention FUD) is likely to keep a lot of people from even experimenting until things are a bit better understood.

One thing that seems a lot less debatable is tools. The tools we have for debugging concurrent programs … well, they pretty much suck. Prints and stack traces (which, in a concurrent world virtually always end up in the scheduler) are significantly less useful than they are in non-concurrent programs. Though it seems we want them, we seem to have not spent as much time on building them. And till we do …

So I have big doubts about this year being the year of message passing. Or even next. Etc. But just like it was with LANs, it doesn’t keep me from having plenty of fun with concurrency while I wait to surf the wave that I do think, everything above notwithstanding, is inevitable.