Coming IO features in Tango

[Sean Kelly]

Ingo Oeser wrote:
> Lars Ivar Igesund wrote:
> 
>> 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.
> 
> Will it be possible to globally disable that or compile a version 
> without that feature and have the application not noticing that?
> 
> Reason is the that the Tango scheduler for these will NEVER be efficient
> enough to do that right, since it just doesn't know enough about the system
> global state to make scheduling decisions at all. Are you sure, you load 
> each Core properly? Use HT properly? Schedule correctly for NUMA? Do you
> solve priority inversion properly? Can you schedule correctly being 
> part of distributed (operating) system? What about real time?

I think the proposed IO system will largely be a generalized abstraction 
for multiplexing mechanisms provided by the OS: IOCP on Win32, epoll on 
Linux, etc.

> You'll also have much fun with unixoide systems and signals, if you do that.
> 
> What about something like jobs and job queues? 

I've been thinking about adding these anyway, though it might be kind of 
interesting to mix job processing with the IO dispatch mechanism.

> Or even better: Support OpenMP! GCC 4.2.x has everything there already, 
> and I'm sure DMD will get this one day :-)
> 
> Fibers, Greenthreads and user space threading stuff like that proved to be
> a can of worms already and is only necessary, if the native thread
> implementation of an OS sucks. 

Fibers/Coroutines are useful in that they vastly simplify the creation 
of state machines in many cases.  They certainly aren't suitable for 
every task, but I think they have enough general utility that they 
should be available to the user.

Green may be another story however, because such designs typically imply 
some sort of scheduling mechanism and such.  I'm simply not convinced 
that there's any way to implement them effectively in a language like D. 
  And besides, some OSes take care of this for you--Solaris, for example.

> For these thread challenged platforms, just provide a user space threading 
> solutions deeply embedded and hidden in Tango.
> 
> Oh and one thing: Never ever start threads in a library! The garbage 
> collector stuff is necessary and ok, but anything more is going to lead to
> hard to debug deadlocks and priority inversions. Had fun with such an ATI 
> library already :-/

Thread pools are a common tool for multiplexed IO.  So much so, in fact, 
that it's impossible to use IOCP without one.  But I agree that 
libraries shouldn't take control away from the user.  In fact, my 
personal approach with Tango is that it should be easy to use in the 
average case, but provide an elegant means to get "to the metal" for 
discerning programmers.  I think we have succeeded thus far, and hope 
that this can extend to the new IO package as well.


Sean