Interview With Revactor Developer Tony Arcieri

with the recent release of his revactor library , i wanted to talk with tony arcieri about ruby, actors, and revactor. he was kind enough to sit down for a short interview. here’s what we talked about.

how did you get started with ruby?

tony ruby is a language some roommates of mine were using for years and kept raving to me about. unfortunately, i was a performance-obsessed c programmer and couldn’t really get past the whole “ruby is slow” stigma. then in early 2005 rails started generating a lot of buzz, and i got sucked into using ruby for web development. a few years later i can look back wondering how i could stand programming in c for so long.

revactor is an implementation of actors for ruby 1.9. is there a reason you targetted 1.9 instead of rubinius (with tasks) or another implementation?

tony ruby 1.8 already supports actors with the omnibus concurrency library and rubinius supports them in its standard library. i’m not aware of an actor model implementation for jruby but it’d be pretty easy to do with a scala-like thread pool. i chose ruby 1.9 because i felt that, for the time being, it’s the most practical and performant platform for writing network applications with the actor model. revactor is built on a number of ruby 1.9-specific features, specifically fibers which provide the underlying concurrency primitive. however, revactor is also built on top of an event library called rev whose feature set was tailored for implementing high performance networking within the actor model (although it can be used as a general purpose event library if you so desire). ruby 1.9 contains several features which made writing this event library quick and easy with minimal c code. these include things like support for blocking system calls and non-blocking i/o.

however, i definitely feel that down the road rubinius will be much better suited. rubinius already supports multiple shared-nothing virtual machines which each run in their own hardware thread and can communicate over an internal message bus. using that in conjunction with actors, you can do scatter/gather distributed programming (mapreduce is probably the most famous example of this) which can run a copy of a job on each vm (and thus on its own cpu core) then reduce the results to the final output. with this approach, your program runs n times faster on n cpus.

what do you think about some of the other approaches to concurrency? ( see mentalguy’s page for example.)

tony many of the techniques there can go hand in hand with actors (futures, for example). as far as non-actor approaches, my favorite is probably join calculus as seen in languages like jocaml.

mentalguy has long been involved in concurrency in ruby. i see that you’re using his case gem in revactor. what other influence has he had on revactor?

tony mentalguy has been very helpful in smoothing out the api design and will hopefully be making revactor thread safe in the near future. he’s pointed out solutions to problems which, in retrospect, were pretty obvious but i just didn’t see at the time. we’re trying to put together something of a standard actor api and protocol such that a program written using actors in ruby isn’t tied to a particular implementation and can run on omnibus, rubinius, or revactor. we’ll also hopefully be putting out a cross-compatible gem which bundles up a lot of the standard actor functionality so there aren’t 3 different implementations of the same thing floating around.

you’ve got a great introduction to actors up at your philosophy page , but it’s a little light on code. could you give us an example of revactor at work?

tony there’s a number of code examples available on http://doc.revactor.org which go a bit more in depth as to how actors send and receive messages, but here’s an example of an echo server:

# an example echo server, written using revactor::tcp
# this implementation creates a new actor for each
# incoming connection.

require 'revactor'

host = 'localhost'
port = 4321

# before we can begin using actors we have to call actor.start
# future versions of revactor will hopefully eliminate this
actor.start do

# create a new listener socket on the given host and port
  listener = revactor::tcp.listen(host, port)
  puts "listening on #{host}:#{port}"

  # begin receiving connections
  loop do

    # accept an incoming connection and start a new actor
    # to handle it
    actor.spawn(listener.accept) do |sock|
      puts "#{sock.remote_addr}:#{sock.remote_port} connected"

      # begin echoing received data
      loop do
        begin
          # write everything we read
          sock.write sock.read
          
        rescue eoferror
          puts "#{sock.remote_addr}:#{sock.remote_port} disconnected" 
        end
        
        # break (and exit the current actor) if the connection
        # is closed, just like with a normal ruby socket
        break
      end
    end
  end
end

this doesn’t demonstrate inter-actor messaging (although it’s doing it behind the scenes). however, what you do see is that there’s very little disconnect between using revactor and writing a traditional threaded network server. if you’ve written programs in the past using thread and queue, then moving over to revactor will be easy, and you’ll find actor mailboxes to be a much more powerful way of processing messages.

are there any books, blogs, or websites you’d recommend for learning more about concurrency in general or actors in particular.

tony programming erlang by language creator joe armstrong was immensely helpful in understanding actor-based concurrency, and many of the ideas in revactor are drawn directly from erlang. some of the erlang portal sites such as planeterlang.org also cover concurrent programming in general, particularly with actors.

you can read more about ruby, concurrency, actors, and revactor over at "on ruby":http://on-ruby.blogspot.com (my home blog).