From: Bill Kelly <billk@...>
Date: 2005-09-01T14:03:06+09:00
Subject: Re: [ANN] EventLoop 0.0.20050825.1600

From: "Tanaka Akira" <akr@m17n.org>
> In article <044601c5aa64$6c973eb0$6442a8c0@musicbox>,
>   "Bill Kelly" <billk@cts.com> writes:
> 
> > 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.

Right... For the program I'm writing right now, if I were
using threads, what I'd like is to have is multiple
pairs of threads--a read thread doing

  sock.gets()

and a write thread doing

  sock.puts(line)

... but I'm afraid the #puts will block my whole process,
potentially. . . . So I can break that down into select()
and send() with NONBLOCK ... But then I'm afraid to use
puts() on the same socket, because I fear mixing high-level
gets/puts with low-level send/recv...  So I presume I need
to break both threads into select() and send/recv...

And so it turns into a bigger chore than it ought to be
in Ruby... :(   And so at that point I think why not just
have one thread with a central select() ...

Well, ... come to think of it - another reason I'd decided
to try a central select() again, was my previous program
that massively used threads in ruby would pause occasionally,
and I could never track down what the heck the process was
doing when it was paused.  (This wasn't the UDP checksum
thing - these were pauses from maybe a fraction of a second
to 2 or 3 seconds.)  It just happened frequently enough to
be annoying, but infrequently enough that it was difficult
to trace.... And so I remember thinking, if this were single-
threaded, it would be--in theory-- easier to determine where
program was paused in these situations.

However - I deduced later, it may have been doing garbage
collection and causing page swaps.  (I had a large in-memory
hash table.)  If that were the case, the mystery would have
been the same in a single-threaded ruby app.  :)

So - I don't know.  One thing I'm sure of is that if Ruby
handled nonblocking better behind the scenes, network 
programming in ruby could be as much of a joy as most other
ruby programming is.

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

Is this new?  I don't seem to have File::NONBLOCK in my
ruby 1.8.2 (2004-12-25) [i386-mswin32]


Regards,

Bill