

Introducing Phat, a new approach to asynchronous Rails apps - _pius
http://www.mikeperham.com/2010/04/03/introducing-phat-an-asynchronous-rails-app/

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

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

~~~
sandofsky
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.

~~~
sreque
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.

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

[http://www.igvita.com/2009/05/13/fibers-cooperative-
scheduli...](http://www.igvita.com/2009/05/13/fibers-cooperative-scheduling-
in-ruby/)

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

~~~
sreque
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.

------
JimBastard
node

~~~
ghotli
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.

