Fibers & Cooperative Scheduling in Ruby
igvita.com
igvita.com
Also, if Ruby really does schedule an I/O-locked thread for its full slice regardless of it being locked, that's Ruby's problem, and "fixing" that is not an advantage of cooperative scheduling. However, I doubt Ruby works that way. Somebody please tell me it doesn't.
It's a great tool for many other tasks, no question. But it's really questionable to use it for scheduling. If you feel it's the best tool, be sure you understand the tradeoffs before diving head-first on the basis of one article's breathless summary. There are reasons this approach has been abandoned for scheduling, and why virtually nobody is proposing that it come back for that purpose, even with all the recent interest in such matters.
Ruby 1.9 implements native threads, so a native extension blocked on I/O will be rescheduled by the kernel, assuming that the native extension unlocks the GIL before performing the I/O operation.
Say you're in the kitchen in front of the refrigerator, thinking about a sandwich. You take a continuation right there and stick it in your pocket. Then you get some turkey and bread out of the refrigerator and make yourself a sandwich, which is now sitting on the counter. You invoke the continuation in your pocket, and you find yourself standing in front of the refrigerator again, thinking about a sandwich. But fortunately, there's a sandwich on the counter, and all the materials used to make it are gone. So you eat it. :-)