[Ruby] Threads or DRb?

Question

I need to have 2 (or maybe 3) continuously running "facets" of a program in Ruby - a communications thread, a render thread and maybe a caching thread.

The idea is the rendering thread shows a slide-show (whose definition is read from file) and all slides are retrieved from a remote HTTP server by the communications thread. The rendering must be continuous and without stops (hence the probable need for caching). The file may change over the course of the program's lifetime and thus need re-parsing (on the fly).

I would like to send messages between the "facets" like when the comms thread gets a whole "chapter" of the show, the render thread could start before waiting for the whole show to be downloaded, for example, and so on.

Should I use Ruby threads or DRb? How can I pass messages between the threads?

Thanks for any feedback!

Answer 1

Keep it simple to start with - always the best advice. Start with just two threads and see if the performance is what you need. You can use condition variable or simple Mutexes to synch around a list of retrieved chapters. You'll possibly get the problem of underrun - no chapter available for rendering but you'll at least have the bones of a workable solution using nothing more than core Ruby.

Then by all means look at solutions which offer other possibilities. Apart from DRb, you should also look at EventMachine (for the asynch capabilities you may need when reading chapters) and RabbitMQ for the more general and looser coupling that a messaging system offers.

Start small and don't try to move too fast. For anyone who has concerns about Ruby threads, I'm running a small report rendering client listening on a RabbitMQ queue. The client uses four threads for rendering the (google) graphs, sending alerts and automatically resetting various queues (after several hours of data have been gathered). All works great!

Chris