From: ptkwt@... (Phil Tomson)
Date: 2004-11-27T03:57:56+09:00
Subject: Re: [ANN] Multiplexer - linear non-blocking I/O

In article <87r7mgzo8x.fsf@igloo.phubuh.org>,
Mikael Brockman  <mikael@phubuh.org> wrote:
>"Robert Klemme" <bob.news@gmx.net> writes:
>
>> "Mikael Brockman" <mikael@phubuh.org> schrieb im Newsbeitrag
>> news:87vfbszr5m.fsf@igloo.phubuh.org...
>>
>> > Blocking I/O is really easy to use.  But when you use it to write
>> > servers, you run into problems: you can't run two blocking syscalls
>> > simultaneously.  So if you're writing a huge file to some guy, every
>> > other client is stalled, and no one new can connect.  Unacceptable,
>> > for many types of servers.  They need non-blocking I/O.
>> >
>> > Non-blocking I/O is a lot more annoying to use.  Instead of going
>> 
>> <snip/>
>> 
>> > It'll run in one thread.  Multiplexer handles the select(3) calls.
>> 
>> What is the advantage over a solution with threads?  IOW, why should I
>> use multiplexer over individual threads per connection?
>
>Since Ruby's threads aren't native, you can't do I/O from several at a
>time.  So one IO#read call blocking for a long time will block the other
>threads, too.  You could loop a read with a time-out, I guess.  But with
>a single thread running select, the whole process can stall completely
>while waiting for I/O.  And it's more elegant.  :-)
>

But if I'm not mistaken, isn't callcc implemented with threads in Ruby?

Phil