From: Tanaka Akira <akr@...17n.org>
Date: 2005-10-04T13:21:49+09:00
Subject: Re: state of blocking/nonblocking I/O

In article <3qctcuFecn8gU1@individual.net>,
  "Robert Klemme" <bob.news@gmx.net> 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.
-- 
Tanaka Akira