On 06/13/2008 12:22 PM, Jeanfrancois Arcand wrote:
> Salut,
>
>> XNIO is not an NIO framework; it is an NIO *replacement*, designed to
>> eliminate the "bad stuff" in NIO like Selectors but keep the "good
>> stuff" like Channels, without imposing significant additional
>> overhead. The default implementation uses NIO.1 under the covers, but
>> an APR-based provider is in the works. There are other good features
>> as well, but I won't pollute the Grizzly list with advertisements for
>> my own project (too late?).
>
> Naaa you don't pollute. Feel free to send us more information. Might
> want to evaluate if we can run on top of your stuff :-) :-)
Haha, ok. Basically the motivation behind XNIO is my feeling that NIO got
it completely "backwards". Because everything is defined in terms of
Selectors, and what a Selector can manage, the capabilities and types of
channels that are available are severely limited - pipes and TCP/UDP
sockets basically. Not only that but it is not possible (as of JDK6
anyway) to implement a fully conforming alternate SelectorProvider without
accessing JDK vendor-specific classes, due to the interruption requirements.
By removing Selectors from the equation, it's easier to make channels for
higher-level concepts like virtual channels, or alternate implementations,
like an OpenSSL channel for example; or channel implementations that are
not strictly portable like UNIX domain sockets. How many times have you
heard of people who don't understand the relationship between Selectors and
the underlying OS file-polling mechanism complaining that they can't
subclass SelectionKey or whatever, to add their own channel types to a
Selector? :-)
Also, I find the callback style to be much more "natural" than the Selector
way of scanning the selected key set - which is to say nothing about the
Selector locking nightmare if you try to share them between threads, or
implementation problems (like
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6403933 for example)
related to how selection keys are defined. Using callbacks is much more
friendly to the more modern IoC paradigm as well - in other words, rather
than start writing your application from boilerplate Selector management
code, you start from the other "end" - write your handler first, and let
your IoC container take care of configuring the socket, server, serial
port, etc. It lets you get to the "meat" of the application much more quickly.
Also planned for 1.1.0 are additional NIO.2-like features such as async
read/write support, though I'm not really sure how useful async read is by
itself, compared to channel polling, or even good old blocking I/O. :)
Also the ability to switch a channel between blocking and non-blocking mode
is being considered.
In any case, any application or framework using NIO should be able to use
XNIO equally effectively (if not more so).
>> I won't go into the differences between Netty and XNIO, but suffice to
>> say that Netty is not an "NIO framework" either; rather it's a codec
>> framework, which uses NIO (or alternately, XNIO) as a lower transport
>> layer.
>
> Netty support XNIO? Or it is planned?
I believe so, though I don't want to speak for Trustin. Perhaps he will
notice this thread and add his comments. :)
- DML