"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.  :-)