Coming IO features in Tango

[Daniel919]

> To make the Tango development process more transparent, we will start
> announcing new and coming features outside of the release cycle itself.
> This may be important changes to Tango, notable feature additions or
> particularly exciting compatible libraries. They will be about features
> already near-finished or well on the way, to avoid false pretences.

Sounds like a good idea to keep the community informed about tango's 
progress.


> Further on, we're building an asynchronous I/O library based on Tango's IO
> abstractions with notifications sent on completion of I/O events. The plan
> for the first stage of development is to have an API capable of delivering
> I/O, timer and (possibly) Unix signal events to applications through
> delegates. It will be able to efficiently handle large numbers ( i.e.
> thousands) of active file descriptors/handles (sockets, pipes, etc.) on all
> the platforms that Tango supports. Initially the library will work both on
> Windows (using I/O completion ports) and on Linux (using epoll); we will
> then provide a Mac OS X and FreeBSD implementation (based on kqueue), and
> other platforms if there is enough interest from the community.

The funny thing is, I just created a class that does handle
onConnect, onRead, onTimeout, onClose, onError, ...
via delegates, using the selector package.
It even handles SSL (openssl wrapped with bcd).

My solution is relatively simple:
It's like: if (selectionKey.isReadable()) { resetTimeout; onReadable(...); }
Each object has a timeout value stored. Before the select
call I lookup when the next timeout should occur and then I do like:
select(nextTimeout - Clock.now).

I'm really interested to see, how the new tango implementation of this 
and my simple solution will differ.


> During the second stage of development we will build a framework on top of
> the asynchronous I/O library that will be able to multiplex I/O jobs using
> Tango Fibers (i.e. lightweight or userspace threads). Each fiber waiting
> for I/O events will be suspended until the event is received, helping to
> avoid consuming excessive resources. The load from each fiber will be
> distributed among a pool of threads.

This is something I didn't implement in my solution so far.

> ... pool of threads.
So the load can be divided and will use all cores of a multi-core machine?


> The idea behind both libraries is to be able to efficiently implement
> network protocols that are either synchronous (HTTP, SMTP, etc.) and
> asynchronous (XMPP, etc.) in nature in both client and server applications.

Like I already said in IRC, for this idea SSL support would be nice.


Best regards,
Daniel