You definitely don't want to farm HTTP requests into threads.

Farm CPU bound code onto threads, keep IO bound code on the main event loop.

Use em-http-request to do HTTP requests on the event loop.

James
On Dec 2, 2011 5:54 PM, "Dmytrii Nagirniak" <[email protected]> wrote:

>
> On 02/12/2011, at 4:38 PM, [email protected] wrote:
>
> When you're handling I/O and not doing any CPU intensive operations, you
> don't need to use defer.
>
>
> That sounds like my case. Doing HTTP requests and just waiting for the
> response.
> If you don't use defer for that, what else?
>
>
> On 2 December 2011 16:26, Dave Newman <[email protected]> wrote:
>
>>  I think by default it keeps 10 threads around for running async
>> operations.
>>
>> Dave Newman
>> @whatupdave
>>
>> On Friday, 2 December 2011 at 4:09 PM, Dmytrii Nagirniak wrote:
>>
>> On 02/12/2011, at 3:47 PM, [email protected] wrote:
>>
>>
>> Hi Dmytrii,
>>
>> On 2 December 2011 15:37, Dmytrii Nagirniak <[email protected]> wrote:
>>
>>
>> On 02/12/2011, at 3:16 PM, Dave Newman wrote:
>>
>> > You could use eventmachine.
>> >
>>
>> EM uses Threads under the hood. So it's doesn't seem to be cheap.
>>
>>
>> No - it works like node.js.  It uses event-driven I/O based on epoll,
>> which is similar to libev (what node.js uses). It's fast (for Ruby) and
>> cheap.  Anything you can do in node.js you can do with EventMachine,
>> libraries permitting.
>>
>>
>> Hmm. Interesting. The docs say that it does use threads internally:
>>
>> The action of 
>> defer<http://eventmachine.rubyforge.org/EventMachine.html#M000486> is
>> to take the block specified in the first parameter (the “operation”) and
>> schedule it for asynchronous execution on an internal thread pool
>> maintained by 
>> EventMachine<http://eventmachine.rubyforge.org/EventMachine.html>
>> .
>>
>> But I guess it should indeed be cheap enough with the internal thread
>> pool.
>>
>> Thanks.
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Ruby or Rails Oceania" group.
>> To post to this group, send email to [email protected].
>> To unsubscribe from this group, send email to
>> [email protected].
>> For more options, visit this group at
>> http://groups.google.com/group/rails-oceania?hl=en.
>>
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Ruby or Rails Oceania" group.
>> To post to this group, send email to [email protected].
>> To unsubscribe from this group, send email to
>> [email protected].
>> For more options, visit this group at
>> http://groups.google.com/group/rails-oceania?hl=en.
>>
>
>
>
> --
> James
>
> --
> You received this message because you are subscribed to the Google Groups
> "Ruby or Rails Oceania" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected].
> For more options, visit this group at
> http://groups.google.com/group/rails-oceania?hl=en.
>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Ruby or Rails Oceania" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected].
> For more options, visit this group at
> http://groups.google.com/group/rails-oceania?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
or Rails Oceania" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/rails-oceania?hl=en.

Reply via email to