On Mar 8, 2010, at 3:13 PM, Tom Reilly wrote:

> I've used threading with getting several web pages for a long time and =
I've never had any problem so long as you catch errors if a specifc web =
page can't be obtained.
> Tom Reilly
>=20
> 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.
>>=20
>> Would it be "considered harmful" to do:
>>=20
>>   resp_a, resp_b, resp_c =3D nil
>>   thread_a =3D Thread.new { resp_a =3D Net::HTTP.get site_a }
>>   thread_b =3D Thread.new { resp_b =3D Net::HTTP.get site_b }
>>   thread_c =3D Thread.new { resp_c =3D Net::HTTP.get site_c }
>>   thread_a.join
>>   thread_b.join
>>   thread_c.join
>>=20
>> 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.


	IMHO you would be better served using the 'thin' rack comat web =
server and using its async mode along with EM::HTTP::Request. This way =
you could use event driven style to hve zero threads and basically pause =
the clients request connection while you make async calls to all the =
other web services, once they all return then you fire the async =
callback for thin to resume the clients connection and return the =
results.

	Doing it this way will require a bit more mental twisting to get =
all the async stuff correct but it will be far more scalable and will =
serve you much better in the end.

Cheers-

Ezra Zygmuntowicz
ez / engineyard.com