From: Mikael Brockman <mikael@...>
Date: 2004-11-27T04:01:06+09:00
Subject: Re: [ANN] Multiplexer - linear non-blocking I/O

ptkwt@aracnet.com (Phil Tomson) writes:

> 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?

It is, but I don't think that several ``continuation threads'' run
concurrently.  In any case, there is definitely only one thread doing
the I/O.