Curtain Call for Ruby

Corey — Tue, 04 Aug 2009 12:43:00 +0000

Unless you have been living under a rock, or don’t program, you know that the software world has been abuzz about the end of “free lunch” — i.e. we can no longer just toss “more horsepower” at our problems, in a traditional manner, and expect a speed-up to occur. Instead, we have to go parallel. One of the most successful ways in doing this is by using the Actor pattern, exemplified in Erlang, which has been known to have 99.99999% up-times in real-world applications.

Being a fan of Ruby, I wanted to see if anyone had implemented the Actor pattern yet. It wasn’t a hard concept — you just provide the class with a mail-box and a way to check and parse messages. The issue falls in Ruby’s threads — namely, they are big and bulky. To have lots of actors, we need a light-weight implementation. What is worse is that Ruby suffers the same problem as Python when it comes to concurrency — the global interpreter lock (GIL) prevents the virtual machine from executing more than one instruction at a time. So even though you might be running separate OS threads on multiple cores, the speed is limited by a single core. So basically, using 1.8, the Actor pattern is a waste of time.

The stable release of Ruby 1.9 seems to tackle the issue head on, by providing Fibers. With 1.9, I was able to find the (now defunct) revactor gem, which seemed like a fairly good (though poorly documented) implementation of the Actor pattern. I also found journeta (which works on 1.8), which was a system that performed network auto-discovery. With the power of these two combined, and some horrible spaghetti code, I whipped together a little gem called ‘curtaincall’, which allows end-users to spawn actors on other machines.

Unfortunately, not everything turned out as well as I would have liked. Revactor seems to break down … or at least, its dependency Rev does, in signaling the mailbox that it has a new message. I can’t quite seem to figure out why this occurs, so as it stands, curtaincall actors never end up receiving the messages passed to them. Furthermore, the method I used of identifying actors is horrible — though it gets the job done. Finally, Erlang niceties like ‘spawn_link’ are poorly implemented and untested.

Ultimately, once I hit the road-block with Revactor, I just gave up. Revactor is undocumented and discontinued. I just wanted to see if I could do this for fun.

The pros? Journeta is a delight to work with. Easy to figure out from the examples provided, and it works just as promised out of the box.

Cons? Just about everything else.

curtaincall-0.0.1

Flirting With Models » distributed

Curtain Call for Ruby