Re: epoll Ada binding

[Ole-Hjalmar Kristensen <ole-hjalmar.kristensen@substitute_employer_here.com>]

>>>>> "ML" == Mark Lorenzen <mark.lorenzen@ofir.dk> writes:

    ML> Wojtek Narczynski <wojtek@power.com.pl> writes:
    >> Hello,
    >> 
    >> > It would be very impressive if you succeed in making an efficient
    >> > task-based implementation with 10000 concurrent connections.
    >> 
    >> The first step is to create a lightweight userspace tasking runtime, then
    >> make the scheduler IO aware. First I tried to rewrite FSU threads in Ada,
    >> function by function, structure by structure. Currently I perceive it as
    >> truly moronic. After having taken a good look at OpenRavenscar and Jose
    >> Tasking Kernel, I think I am on the right track. I have a lot of
    >> functionality working. One humongous missing piece is signals /
    >> interrupts. After all that making the scheduler IO aware will be a piece
    >> of cake.

    ML> OK, so it requires a special run-time system. If the tasks are I/O
    ML> aware, will the "usual" Ada task behaviour be preserved?

    ML> For some time I have been thinking how to make a library, which can be
    ML> used for the purpose of building networking applications. But instead
    ML> of patching the run-time system, I was thinking of a library which
    ML> could provide Ada equivalents for SDLs process and service
    ML> constructs. When providing a process set, the library user could
    ML> choose to have a process set where each process was a co-procedure
    ML> (i.e. one task handles many connections) or choose to have a process
    ML> set where each process was a task (i.e. one task handles one
    ML> connection). The choice could be mde by instantiating from different
    ML> packages or inheriting from different classes.

But wouldn't it be better if the built-in tasks could be made lightweight
enough by changing the run time system? Then you would not have to
choose between two different task types, and all your familiar
abstractions would work. Actually I miss Occam on the transputers,
where task switching had the same cost as a subroutine call.

    ML> If this library also could provide a general way of implementing state
    ML> machines (a tagged type for each state?), it would provide powerful
    ML> infrastructure for networking applications.

I think this is better handled by a program generator, like this one: 
http://smc.sourceforge.net

    >> 
    >> The #1 obstacle is my regular job ;-)
    >> 
    >> Thanks for the reassurance that my thinking is sound, I need it...
    >> 
    >> Regards,
    >> Wojtek

    ML> - Mark Lorenzen

-- 
   C++: The power, elegance and simplicity of a hand grenade.