From: Richard Conroy Date: 2010-03-09T09:02:33+09:00 Subject: Re: asynchronous network access with Rack? --0015175caa56d4a7ff048152e558 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Mar 8, 2010 at 10:50 PM, Nick Brown 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 for Rails, GIL & native gems, and a general lack of robustness in older Ruby thread implementations). > Would it be "considered harmful" to do: > > resp_a, resp_b, resp_c = nil > thread_a = Thread.new { resp_a = Net::HTTP.get site_a } > thread_b = Thread.new { resp_b = Net::HTTP.get site_b } > thread_c = Thread.new { resp_c = Net::HTTP.get site_c } > thread_a.join > thread_b.join > thread_c.join > > 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 count. Whats more important is that this model isn't exactly a good architecture. You are spawning a lot of threads per request and you have no real external oversight into how they are working. You can't send back your response until you have received all your outbound responses and you are particularly vulnerable to timeouts - in particular the client browser can timeout your request, while you are still waiting on responses to outbound connections. You see a lot of solutions that use process level concurrency (BackgroundRb, DelayedJob etc) but most web solutions that aggregate content from multiple sites (i.e. mashups) do it all in the browser, with some cross site scripting & javascript. Technically I dont see too many issues with the multi-threaded approach you propose for smaller requests, but you will want to set an aggressive timeout on the outbound requests. -- http://richardconroy.blogspot.com --0015175caa56d4a7ff048152e558--