Dramatis Platform FAQ
What is dramatis written in?
Currently, the implementation is Ruby and Python. Other sufficiently similar languages are possible, for some definition of "sufficiently similar".
What is "sufficiently similar"?
I'm not entirely sure. Here's what I would guess:
- Object-oriented
- Dynamically-typed
- Imperative
- Has a "method missing" like function
- A reasonable metabject protocol
I don't think it needs open types, but since both Ruby and Python have them, I'm not sure. I'm not sure how much of a metaobject protocol it needs. It probably doesn't need everything it uses right now.
What versions of Ruby does it run on?
On Linux, 1.8.6 (p114), 1.9 (a recent trunk), and JRuby (a recent trunk). On OS X, I think it's the same. I haven't looked at Windows at this point.
I did one very simple test ( source:examples/pingpong/actor.rb ) on a recent trunk of rubinius and it worked.
What versions of Ptyhon does it run on?
I've only tried it on Python 2.5 on Linux.
Does it use Threads?
Yes.
Does the Ruby 1.9 version use Fibers?
No.
What kind of threads? Green threads or OS threads?
Whatever the implementation provides. Dramatis doesn't care, but some programs will behave somewhat differently on different platforms.
What does Dramatis buy you on green threads platforms like Ruby 1.8.6? Does multicore buy you anything?
To the latter, nope.
To the former: two things. First, it provides the actor model, which makes writing event- and data-driven code easier since you don't have to write your own scheduler.
Second: even green thread implementations handle overlapping I/O. See the futures example in the actor FAQ. This was one of my first use cases.
But blocking in a C extension blocks everything in Ruby 1.8.6?
Yup. Two common examples of this are, I believe, GUI toolkits and DNS lookup. That doesn't make them useless, though. See the FOX IM example.
What about Ruby 1.9 and Python? Will multicore buy me anything?
I'm not an expert. Ruby 1.9 and Python have GILs, the giant (or is it global?) interpreter lock, and I think that limits the usefulness of multicore. Ruby and Python code isn't going to run concurrently, though extension code might.
JRuby?
As I understand it, ruby code can run concurrently in multiple threads in JRuby so actors should run concurrently. This has been demonstrated to a limited extent using the fib example. In fact, the JRuby folks are using the example to look in to some possible issues in their thread implementation.
So, is Dramatis only ever going to be useful on JRuby then?
No, for two reasons:
First the actor model is just nice and the I/O overlapping is nice. Even on a single core. My first use case didn't call for concurrent threading.
Second, on the road-map is the ability to run multiple processes with socket-based message passing. Actors in different processes can run concurrently.
Won't the socket I/O be expensive?
Grain size, i.e., the ratio of computation and communication, is always an issue in concurrency if processor utilization is a driving factor. Dramatis is no exception and I don't know what its ratio will be at this point. But I have plenty of reasonably coarse-grained needs that I'm not worried about it.
My needs are more about overlapping I/O and large loosely coupled, resilient systems and for those, Dramatis with sockets should be fine.
If anyone wants to rewrite this FAQ to not be in the first person, go for it.