------art_10561_12144450.1162359721649
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 10/31/06, ara.t.howard / noaa.gov <ara.t.howard / noaa.gov> wrote:
>
> On Wed, 1 Nov 2006, Bjorn Borud wrote:
>
> > [ara.t.howard / noaa.gov]
> > |
> > | it can't be done.  search the archives, this sort of thing almost
> > | always indicates a design flaw.  for instance - what will your
> > | program do if there is no input?
> >
> > nonblocking IO is not a design-flaw; it is something that is in common
> > use and is supported by most languages with a decent socket API.  on
> > some OS'es this is even available for file IO (although widespread
> > language support seems to lag behind).
> >
> > Java for example got proper nonblocking socket IO in 1.4 (see
> > JSR-000051 "New I/O APIs for the JavaTM Platform").
>
> but it's archaic compared to event driven frameworks like



Ara, I'm curious to know why you think the usage of nbio is archaic or
indicative of a design flaw. I wrote the EventMachine library in order to
make certain kinds of Ruby programs easier to write, and it uses nbio
pervasively. I'm fairly sure libevent does, also. EM works with almost any
kind of descriptor, except for certain things on Windows (like _pipe()
descriptors, which are nonselectable, and some of the native Windows objects
that don't support a socket-like API).

Up until recently (late May 2006), Ruby didn't have complete support for
nbio on all descriptor types, which is one of the reasons that EventMachine
includes a compiled C++ extension. EM interoperates perfectly well with Ruby
threads,* which is another important reason to use nbio.



---
*Except for certain cases on Windows where Ruby code that accesses standard
descriptors blocks all other Ruby threads. But this is not an EM issue,

------art_10561_12144450.1162359721649--