Coming IO features in Tango

[Juan Jose Comellas]

The problem with your approach is that it won't scale very well on Windows.
The Selector implementation on Windows uses the select() API, which is very
inefficient. The new I/O interface will use I/O completion ports, which
scale much better but are inherently asynchronous and not appropriate for a
selector-like interface.


Daniel919 wrote:

>> 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