Re: state of blocking/nonblocking I/O
- From: Mark Cotner <mcotner@xxxxxxxxx>
- Date: Wed, 5 Oct 2005 04:32:28 +0900
Here's an example that I tested recently. The application is a network
management framework for polling millions of devices per hour. Threads are
nice, but context switching between enough threads to get the job done(175
per my testing) generates a ton of CPU load(~load jumps to 30 and 0% idle on
4 CPU box) when trying to maintain this many threads. It was written in the
producer/consumer pattern so thread startup isn't compounding the issue.
However, the same application using Perl('cause Ruby can't do this just yet)
asynchronous SNMP polls twice as many devices in the same amount of time
with 2-4 processes and the system load is ~1 and ~70% idle.
Granted, I'm doing some fairly extreme things, but it does help answer the
question of threads vs async IO.
'njoy,
Mark
On 10/4/05 9:40 AM, "Ara.T.Howard" <Ara.T.Howard@xxxxxxxx> wrote:
> On Tue, 4 Oct 2005, Tanaka Akira wrote:
>
>> In article <3qctcuFecn8gU1@xxxxxxxxxxxxxx>,
>> "Robert Klemme" <bob.news@xxxxxxx> writes:
>>
>>> I have one question on this matter which I still don't understand (I'm not
>>> so deep into C stdlib IO variants so please bear with me): why would anybody
>>> want to use nonblocking IO (on the Ruby level, e.g. IO#read might not have
>>> read anything on return even if the stream is not closed) in the light of
>>> Ruby threads? I mean, with that one would have to build the multiplexing in
>>> Ruby which is already present in the interpreter with multiple Ruby threads?
>>> Are there situations that I'm not aware of where this is useful / needed?
>>
>> It is an interesting question I also have.
>>
>> I asked it several times, so I know some answers.
>>
>> 1. GUI framework has its own event driven framework.
>>
>> If a callback blocks, it blocks entire GUI. It is not
>> acceptable.
>>
>> 2. High performance network server has its own event driven
>> framework.
>>
>> Some high performance network servers use an application
>> level event driven framework. If an event handler blocks,
>> it blocks entire application. It is not acceptable.
>>
>> However I'm not sure that it is appropriate to implement
>> a high performance server in Ruby.
>>
>> If an application level event driven framework is used,
>> application level nonblocking I/O operations are required.
>>
>> If there are other usages, I'd like to know.
>
> it's sort of the same thing as 2, but network intense clients might me written
> more easily too... i've written code that was managing 100s of ssh connection
> for example. i could have used threads but it was easier/more responsive to
> just have an array of pipes and non-blocking reads.
>
> the only other thing i can think of is any time you may actually be fine
> blocking on a read, but wish to remain aware of time - eg. you don't want to
> block too long - and here something like readpartial is great.
>
> -a
.
- References:
- Re: state of blocking/nonblocking I/O
- From: Ara.T.Howard
- Re: state of blocking/nonblocking I/O
- Prev by Date: Re: The definitive GUI for Ruby
- Next by Date: Re: The definitive GUI for Ruby
- Previous by thread: Re: state of blocking/nonblocking I/O
- Next by thread: Re: state of blocking/nonblocking I/O
- Index(es):
Relevant Pages
|
