On Mon, Mar 8, 2010 at 10:50 PM, Nick B. [email protected] wrote:
I’ve read that “threading is considered harmful” for Ruby web apps.
Well, I’m writing a Sinatra app which will build a page based on the
responses of several servers (Net::HTTP.get). I want to do these .gets
in parallel, as doing them synchronously would obviously mean the users
would wait for a long time.
There are some historical reasons behind threading == harmful (defaults
GIL & native gems, and a general lack of robustness in older Ruby thread
Is there any possible harm that could come from this? Can threading
interfere with Rack in some way? I haven’t done much previous
development of threaded apps, so I would appreciate any tips.
I believe Sinatra/Rack is thread safe, so you should be fine on that
Whats more important is that this model isn’t exactly a good
You are spawning a lot of threads per request and you have no real
oversight into how they are working. You can’t send back your response
until you have received all your outbound responses and you are
vulnerable to timeouts - in particular the client browser can timeout
your request, while you are still waiting on responses to outbound
You see a lot of solutions that use process level concurrency
DelayedJob etc) but most web solutions that aggregate content from
sites (i.e. mashups) do it all in the browser, with some cross site
Technically I dont see too many issues with the multi-threaded approach
propose for smaller requests, but you will want to set an aggressive
on the outbound requests.