Skip to content

Instantly share code, notes, and snippets.

@jackdempsey
Created April 7, 2011 00:59
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 1 You must be signed in to fork a gist
  • Save jackdempsey/906844 to your computer and use it in GitHub Desktop.
Save jackdempsey/906844 to your computer and use it in GitHub Desktop.
Thanks Xavier, I too am a big fan of the style. It’s an honest capturing of what it’s like to learn this sort of thing for the first time (or in my case with fibers, the 10th).
Everything was clear up til the end, which is where the details get fuzzy for me.
If I could add in my $.02 to this final chunk:
class Surprise < Goliath::API
def response(env)
f = Fiber.current
EventMachine.add_timer 1, proc { f.resume }
Fiber.yield
[200, {}, "Surprise!"]
end
end
1. This code is running in the context of a currently executing fiber. This is why you can't just pop into irb and call Fiber.current (you have to require 'fiber' before you do that).
2. The EventMachine call is important to clearly understand. As documented here http://eventmachine.rubyforge.org/classes/EventMachine.html#M000013 "EventMachine#add_timer is a
non-blocking call." So after that line executes we immediately go to the next line.
3. Fiber.yield returns control to the calling fiber. Things are halted at this point.
4. Goliath goes and processes the next request and goes through the same steps, in this case, 2 more times 5. One second after that first add_timer call, the callback is
executed and the f.resume call resolves and grabs control back from goliath, at the point at which is was stopped (the Fiber.yield location). We then return the rack result at this point.
6. This happens 2 more times for the other callbacks and the result is that 3 responses occur in just over 1 full second. How's this sound to everyone else? Clear? Correct? :-)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment