From: Tanaka Akira <akr@...17n.org>
Date: 2005-08-27T07:56:51+09:00
Subject: Re: [ANN] EventLoop 0.0.20050825.1600

In article <044601c5aa64$6c973eb0$6442a8c0@musicbox>,
  "Bill Kelly" <billk@cts.com> writes:

> I'm about to head to the airport so I'll just say that
> I'm still experimenting.  I sometimes develop a system
> with threads, because I think select() was a pain in the
> last system I did.  Then I get annoyed with the new
> threaded system, and go back to select() on the next one.
>
> I keep encountering trade-offs, and I'm not sure which
> way I like best.

The trade-off should not big except programming style issue since Ruby
thread mechanism use select().  You use select() anyway, directly or
indirectly.  The thread mechanism can do what IO.select can and vice
versa, in principle.

However Ruby doesn't support non-blocking I/O well, yet.  It tends to
be a problem for event driven programs which use IO.select.

> Well, what if we were to add a #nonblocking= method to IO,
> or at least to Socket?

I heard sock.fcntl(Fcntl::F_SETFL, File::NONBLOCK) makes sock
nonblocking mode on Windows.  However sock.fcntl(Fcntl::F_GETFL)
doesn't work.

There is io/nonblock which add IO#nonblock and IO#nonblock=.  I don't
know it works on Windows.
-- 
Tanaka Akira