Concurrency with Fibers and EventMachine

Concurrency in Rails - a bug that bit me few weeks back. This led me to read in detail about "Reactor Pattern" (EventMachine, Twisted, Node.js) and making requests asynchronous.

Let me take a step back and tell ya what made me read all this.
Think about if, you had to solve a problem of making multiple service calls to complete a response. Doing this sequentially is "old" architecture, where you did not care much about performance. One can definitely argue, why not cache the beast !
Well,

• what if the data is dynamic
• what if I care more about CPU Utilization.
  

Every service requires I/O and everyone knows I/O is blocking. So, while waiting for the request to complete, CPU sits idle doing nothing. It could have fired another service call. This is more easy to say then to solve . This is where evented programming becomes very helpful. Consider all service calls as events which you can register for callbacks. You fire them all together and wait for them to complete. But now these events (ruby threads) compete for CPU cycle (yeah for obvious reasons - green thread). The threads are preempted by OS and there is no way you can control this.

Ruby 1.9 introduced this powerful concept of Fibers - of creating code blocks which can be paused and resumed by application developer. So, we can control when to pause and resume the execution ?? yeah
Moreover they are cheap to spin off new as compared to threads.

So, to achieve concurrency, we can fire fibers as events, each fiber responding back to callbacks.
All sweet !!

Wrote a nice Rails app -> fibered-rails

Going to talk about this in our TCS Rails Conf'11 on 02/17/2011 - see the talk here

Fibered rails

View more presentations from toamitkumar