From: Bjorn Borud <borud-news@...>
Date: 2006-11-02T18:00:10+09:00
Subject: Re: Nonblocking IO read

[ara.t.howard@noaa.gov]
| >
| > 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
| 
|    http://www.monkey.org/~provos/libevent/
|    http://liboop.ofb.net/

you are comparing apples and oranges here.  you have to look at where
these things fit into the big picture.  the above mentioned libraries
provide abstractions that are used to provide a more convenient
programming model, and at least in the case of libevent, provide an
abstraction that insulates code from having to deal with supporting
the various readiness selection APIs that exist.  they do not replace
the underlying OS interfaces upon which they are built.

JSR-000051 does more or less the same thing, but with a slightly
different goal in mind.  the primary goal is to provide the programmer
with access to asynchronous network IO in a platform-agnostic
manner. the emphasis is on providing a sensible abstraction that works
well with the various operating system APIs that exist -- exposing a
reasonable common subset of functionality that one can expect to be
able to support on a variety of platforms.  JSR-000051 provides the
primitives on top of which you would implement IO frameworks that
provide conventient programming models.

for a language, providing sensible APIs for primitives is more
important than imposing a particular programming model.  given a set
of sensible primitives that can be widely supported, whatever higher
level frameworks one wishes to create can be built atop that.

| in addition it's a hack in the c lib of many oses.

I am not sure I understand exactly what you mean.  the way I see it
there are three distinct levels to networking APIs:

  1. OS API, that is, the system calls

  2. standardized system libraries, like libc, java.io, java.util.nio
     etc, which provide access to IO primitives and possibly abstract
     away the underlying OS APIs

  3. higher level IO frameworks that provide more convenient programming
     models

libevent would overlap with both 2 and 3 in this case since its
mission is *both* to abstract away the underlying OS interfaces *and*
provide a convenient programming model.  Java's NIO is what you'd find
in 2 and a typical Reactor pattern implementation would be in 3.

(if you use low-level socket APIs (ie the types of functions
documented in section 2 of the UNIX manual pages) on UNIX you will
find yourself using a mix of 1 and 2 if you use C/C++ since you use
wrappers in libc to perform system calls, but this is just a very,
very thin convenience layer on top of the system calls.  if this is
confusing then just forget I mentioned it :-).

| > for examples of use you might want to check out the Reactor pattern
| > and other patterns for concurrent programming.
| 
| afaik the reactor pattern is a synchronous pattern

no, the Reactor pattern is mainly used to implement asynchronous IO
and is not really anything new.  I've both written and seen variations
of this pattern in a multitude of languages since I started writing
networking code in the early 90s and the only thing that has really
changed is that we've gotten better at classifying these types of
patterns, give them better definitions, and give them names.  (when I
started writing networking software in the early 90s, "patterns"
wasn't commonly part of the programmers vocabulary).

|    http://www.artima.com/articles/io_design_patterns2.html
| 
| not unlike the model of libevent and liboop - which are both synchronous...
| am i missing something?

you are missing an "a" in front of "synchronous" :-)

-Bj�rn