Middleware Matters

In my latest Internet Computing column, I explore what it takes to write extensions to Ruby. Imaginatively, I entitled the column "Ruby Extensions" (pdf).

All in all, I've found that writing such extensions is not that difficult. Using the extension APIs to augment your C or C++ middleware with a Ruby interface could quickly increase your productivity. Given that glue code has to be flexible and can change frequently, writing the more fluid parts of your integration in Ruby rather than a compiled language can ease your development and maintenance costs. Extending Ruby with the underlying C++/C middleware means you get this without forcing any reworking of the performance-critical parts of the system. It gives you the best of both worlds and puts you on "easy street." :-)

Unfortunately, due to space issues, I didn't get to cover threading issues in the column. Ruby currently simulates threads in its interpreter, like Java's ancient "green threads," thus making it hard to integrate with the native threading approaches employed by C++/C code. It also obviously makes it impossible for Ruby to take advantage of the multithreading capabilities of today's hardware and operating systems. Since Ruby threads are so weak and more under-documented than even the language itself, Ruby libraries tend to completely ignore threads, making for an overall non-thread-friendly system. For this reason, employing Ruby on the server/receiving side in a multithreaded middleware dispatching system or framework is probably a bad idea, unless you can lock around the Ruby parts and don't mind the resulting performance and scalability issues. I've therefore been keeping my Ruby work on the client or sending side, where it can be largely in control and not subject to the threading whims of the underlying framework. I've heard that Ruby 2.0 is supposed to fix the lack of native multithreading support -- can anybody point to some firm details on that?