Coconut AIO [was AbstractSelectableChannel]

Hi there,

im the author of Coconut AIO (as well as much of the stuff in seda2)

1.
Im a long time user of sandstorm and the functionality of Coconut AIO is really a superset of the functionality provided by the sandstorm io-libraries. The library can also be used in a blocking style or even in a callback style on a per-operation basis. Furthermore there is JMX support and a lot of small tools for debugging your applications. There are also some performance enhancements (compared to the sandstorm io-libraries) and much better exception handling. Finally it got lots of test cases > 200 test cases.

2.
Currently its 1.5 only, but it should be possible to make a 1.4 version without too much trouble. Compared to the alternatives of developing something from scratch, which is a long process (trust me) or fixing the sandstorm io libraries. I would probably go with fixing coconut AIO. However don't expect to be able to make a pre-nio (1.3 and ealier) version. NBIO is dead anyway.

3.
Regarding IBM's AIO, first of all there is the license which is probably   a no go. The other problem with this library is that it is based on futures and doesn't really go well in hand with the Sink/sandstorm approach. So just drop that approach.

4.
Regarding changing blocking state for streaming/datagram sockets by using AbstractSelectableChannel.configureBlocking(boolean block) is a bad idea for a number of reasons. The primary reason is that there is no such thing as a blocking-write nonblocking-read configuration. So if the socket is configured as blocking we need a seperate thread for each blocking socket for reading. This is just a bookkeeping nightmare.
However, im using the approach for an asynchronous serversocket where I've got a (blocking) accept() and a asynchronous accept(Sink someSink).

I think it could be possible without to many problems to implement this blocking functionality. Try, for example, opening http://tinyurl.com/6zpmf and searching for "checkBufferLimit(long bytes)" I figure we would just replace the throw rejectedException with some code that blocks.

5.
Im not to sure about the backpressure mechanism Quartz is talking about.  But non-blocking sockets does not backpressure in anyway.

6.
Finally, I agree with quartz that the sandstorm aiofile library is useless is some sense. The reason I did include a AsyncFile anyway is that I want to be able to write files directly from a disk channel to a socket (which, btw, is not possible in the sandstorm afile lib). The feature is currently only halfway implemented though.

- Kasper 


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/