Introducing Phat, a new approach to asynchronous Rails apps

mikeperham.com

36 points·_pius··8 comments

http://www.espace.com.eg/neverblock is another implementation of the same idea.

Basically green threads. I guess this helps amortize the per-VM Ruby memory overhead.

Not really. From the article:

"single Thread, multiple Fiber"

Fibers are not threads. Rather than preemptive multithreading, it's cooperative. This means the VM isn't wasting time on requests blocked on IO.

Green threads don't waste time on requests blocked on IO either. Both styles involve a software-level scheduler. The only difference between what most people call green threads and what most people call fibers is that one is preemptive and the other is cooperative. I actually prefer coding in the preemptive style.

Please correct me if this article is wrong or I'm misreading it:

http://www.igvita.com/2009/05/13/fibers-cooperative-scheduli...

MRI's fair scheduler means a thread gets an equal time slice even if it's blocked on IO.

I could be wrong, but it was my understanding that, on POSIX systems at least, the 1.8 MRI interpreter was smart enough to use non-blocking IO underneath the hood when performing IO calls and have a thread release its hold on the GIL when it is performing IO. That way, another thread could run while the first thread waits for an IO operation to complete. Either way, whether or not a software-level thread scheduler optimizes by using non-blocking IO or not is orthogonal to whether or not it schedules preemptively or cooperatively.

node

Sure node.js is asynchronous, fast, and fun to work with like rails. I downvoted you because your comment was nearly useless to someone who didn't already know what you were talking about. If you've got some advice, provide supporting information.

Reply on news.ycombinator.com