Darek from classifieds posting service

This patch affects ruby code running on EventMachine with the epoll reactor.

require 'eventmachine'; EM.epoll; EM.run {} # 800k stack on linux on old EM

There may be a similar patch coming for the kqueue reactor, but that is less affected (40k vs. 800k).

require 'eventmachine'; EM.kqueue; EM.run {} # 40k stack on OSX

The issue does not exist in any extreme with the select reactor.

require 'eventmachine'; EM.run {}

You can see the effects of the issue most drastically when using EventMachines defer method, because it spawns up 20 threads, each of which will carry a heavy stack.

I have recently done some research on performance metrics of ruby's green thread implementation. Whilst there is a much more significant impact to ruby's performance when the stack size is large, the specific impact of the number of threads does not become noticeable until high numbers of threads (two orders of magnitude and above (100+ threads)). The choice of 20 threads seems sensible, given this research.

Each spawned thread carries a copy of the stack, though, so if you spawn threads 'later' in your execution stack (like Thin does), then you will see extra performance degradation from these issues. As such the real highlight comes from an app like this:

require 'eventmachine'; EM.epoll
require 'sinatra'; def (Sinatra::Application).deferred?(env); true; end
get '/' do escape_html Thread.current.inspect end

Some of the general impacts of stack size on ruby performance are demonstrated here:
http://pastie.textmate.org/private/iynyujlrzorq...

And can be generated like so:
http://gist.github.com/104213

Maybe I'll collaborate or separately post some ruby programmer oriented explanations of these posts soon. :)