epoll Ada binding

epoll Ada binding

[jn]

Hi,

I am looking for a Linux 'epoll' Ada binding. Any suggestions other
than writing my own.

/jonas

Re: epoll Ada binding

[Mark Lorenzen]

jonas.nygren@telia.com (jn) writes:

> Hi,
> 
> I am looking for a Linux 'epoll' Ada binding. Any suggestions other
> than writing my own.
> 
> /jonas

I think you have to write your own. But do you really need epoll? It
is not POSIX compatable and only necessary when you have many (over
10000) concurrent connections.

- Mark Lorenzen

Re: epoll Ada binding

[jn]

Mark Lorenzen <mark.lorenzen@ofir.dk> wrote in message news:<m38ya37pyf.fsf@0x5358c0d0.boanxx18.adsl-dhcp.tele.dk>...
> jonas.nygren@telia.com (jn) writes:
> 
> > Hi,
> > 
> > I am looking for a Linux 'epoll' Ada binding. Any suggestions other
> > than writing my own.
> > 
> > /jonas
> 
> I think you have to write your own. But do you really need epoll? It
> is not POSIX compatable and only necessary when you have many (over
> 10000) concurrent connections.
> 
> - Mark Lorenzen

The goal for my programming exercise is to be able to handle 10 - 100
000 concurrent connections effectively :).

/jonas

Re: epoll Ada binding

[Wojtek Narczynski]

Hello,

> The goal for my programming exercise is to be able to handle 10 - 100
> 000 concurrent connections effectively :).

I am currently working on a modified runtime that will use IO readiness
for task scheduling. I have basic task switching working. I am able to
create 10K tasks, but I don't know if it is going to work for 100K tasks,
because of memory consumption. But my goal is to handle many connections
maintaining the task-based way to program. Epoll is one of the bits I am 
going to miss, so if your work will be Modified GPL, please talk to me.

Regards,
Wojtek

Re: epoll Ada binding

[Mark Lorenzen]

Wojtek Narczynski <wojtek@power.com.pl> writes:

> Hello,
> 
> > The goal for my programming exercise is to be able to handle 10 - 100
> > 000 concurrent connections effectively :).
> 
> I am currently working on a modified runtime that will use IO readiness
> for task scheduling. I have basic task switching working. I am able to
> create 10K tasks, but I don't know if it is going to work for 100K tasks,
> because of memory consumption. But my goal is to handle many connections
> maintaining the task-based way to program. Epoll is one of the bits I am 
> going to miss, so if your work will be Modified GPL, please talk to me.
> 
> Regards,
> Wojtek

It would be very impressive if you succeed in making an efficient
task-based implementation with 10000 concurrent connections.

- Mark Lorenzen

Re: epoll Ada binding

[Wojtek Narczynski]

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.

The #1 obstacle is my regular job ;-)

Thanks for the reassurance that my thinking is sound, I need it...

Regards,
Wojtek

Re: epoll Ada binding

[Mark Lorenzen]

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.

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

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

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

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

- Mark Lorenzen

Re: epoll Ada binding

[Ole-Hjalmar Kristensen]

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

Re: epoll Ada binding

[Mark Lorenzen]

Ole-Hjalmar Kristensen <ole-hjalmar.kristensen@substitute_employer_here.com> writes:

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

Yes, if task switching can be made lightweight enough. I have worked
with software for telephony switches that may have f.x. 50,000 ongoing
calls. Each call is a long chain of "tasks", so all in all the amount
of tasking resources needed can be very large.

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

I do not know that particular application, but a state machine
compiler could be a good tool.

- Mark Lorenzen

Re: epoll Ada binding

[Wojtek Narczynski]

Hello,

> Yes, if task switching can be made lightweight enough. I have worked
> with software for telephony switches that may have f.x. 50,000 ongoing
> calls. Each call is a long chain of "tasks", so all in all the amount
> of tasking resources needed can be very large.

Wow. Would you be kind enough to give me a hint on how to cope with
such enormous amounts of connections? I mean OS, hardware, programming
language (if all this is applicable at all..). I'm just (utterly) curious.

Regards,
Wojtek

Re: epoll Ada binding

[Mark Lorenzen]

Wojtek Narczynski <wojtek@power.com.pl> writes:

> Hello,
> 
> > Yes, if task switching can be made lightweight enough. I have worked
> > with software for telephony switches that may have f.x. 50,000 ongoing
> > calls. Each call is a long chain of "tasks", so all in all the amount
> > of tasking resources needed can be very large.
> 
> Wow. Would you be kind enough to give me a hint on how to cope with
> such enormous amounts of connections? I mean OS, hardware, programming
> language (if all this is applicable at all..). I'm just (utterly) curious.
> 
> Regards,
> Wojtek

Sorry for the extremely late answer....

In the AXE10 telephony switch from Ericsson, there is no such concept
as task, context switch, pre-emption or stack, when seen from the
programmer's view. The software is executed by an interpreter, which
maintains a huge signal queue. A signal is pop'ed from the queue, the
target address of the signal is analysed and the interpreter jumps to
the correct piece of code. The signal will normally carry some
information in addition to the target address. This information could
f.x. be an "individual number" that identifies which "context" the
signal must be handeled in. When I say "context" I actually mean a
record where persistent data is stored. So we may have an array of
50,000 of these records enabling us to handle f.x. 50,000 connections
and the individual number is the index to use in the array. When we
are finished handling a signal, we voluntarily give up the CPU. When
we give up the CPU, the CPU registers are NOT stored (as we have no
stack) so we must ensure that all persistent data is stored in the
record representing our context.

All in all we have a huge number of co-procedures, where each
co-procedure handles a huge number of contexts. Yet no real
context-switch is performed and the only storage used by an individual
is the size of its context-record.

The AXE10 itself is an impressive piece of machinery. Complete
software upgrades are made during service (ie. when connections are
being established) without any disruption to the users. Fault
frequency is constantly monitored and faults are dealt with by first
releasing the chain of contexts that cause the faults, then (if the
fault frequency is still too high) a small restart is made where all
the stable calls (calls with two-way speech conection) are preserved,
then (if the fault frequency is still too high) a large restart is
made which completely wipes out the calls. The downtime of such an
exchange is extremely low!

Regards,
- Mark Lorenzen

Re: epoll Ada binding

[Wojtek Narczynski]

Mark Lorenzen wrote:

> 
> Sorry for the extremely late answer....
> 

No problem at all :-)

If yo have some more patience for me: How is the queue fed with
signals? What language is this programmed in, Erlang perhaps? How many
CPUs are there?

Regards,
Wojtek

Re: epoll Ada binding

[Wojtek Narczynski]

On Wed, 20 Oct 2004 22:48:00 +0200, Mark Lorenzen wrote:

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

Yes, it is my plan do "stay in Ada". I don't think there is going to be a
problem with that. FSU Threads (userspace) used to be used to pass ACATS
tests on platforms which had problematic native threading libraries.

> But instead of patching the run-time system, 

I'm not really patching it. I am trying to create yet another "flavor".

> I was thinking of a library which could provide Ada equivalents for
> SDLs process and service constructs.

You mean this SDL http://www.sdl-forum.org? I merely know that it exists,
would you recommend studying it to somebody intersted in building
networking applications?

Do you think SMTP (my primary protocol of interest right now) would be
amenable to such (formal) treatment? After all S - stands for Sloppy ;-)

Regards,
Wojtek

Re: epoll Ada binding

[Mark Lorenzen]

Wojtek Narczynski <wojtek@power.com.pl> writes:

> Yes, it is my plan do "stay in Ada". I don't think there is going to be a
> problem with that. FSU Threads (userspace) used to be used to pass ACATS
> tests on platforms which had problematic native threading libraries.

I think that the Native Posix Threads Library used on newer Linux
distributions is very efficient and POSIX compatible. I do not know if
gcc GNAT is up to speed with this or still needs the FSU Threads.

> I'm not really patching it. I am trying to create yet another "flavor".

Sounds like TopLayers approach:

http://www.linuxjournal.com/article.php?sid=3675

(the server seems to be unreachable at the moment).

> You mean this SDL http://www.sdl-forum.org? I merely know that it exists,
> would you recommend studying it to somebody intersted in building
> networking applications?

Yes - the Specification and Description Language. SDL has some
interesting concepts, but is not a wonder in engineering. It is
however (in my view) much better than the state charts in UML.

> 
> Do you think SMTP (my primary protocol of interest right now) would be
> amenable to such (formal) treatment? After all S - stands for Sloppy ;-)

Formal treatment of any protocol is valuable!

> 
> Regards,
> Wojtek

- Mark Lorenzen

Re: epoll Ada binding

[Wojtek Narczynski]

On Fri, 22 Oct 2004 19:56:21 +0200, Mark Lorenzen wrote:

>> Yes, it is my plan do "stay in Ada". I don't think there is going to be a
>> problem with that. FSU Threads (userspace) used to be used to pass ACATS
>> tests on platforms which had problematic native threading libraries.
> 
> I think that the Native Posix Threads Library used on newer Linux
> distributions is very efficient and POSIX compatible. I do not know if
> gcc GNAT is up to speed with this or still needs the FSU Threads.

GNAT does not need FSU Threads for speed, rather for passing ACATS. So if
GNAT over FSU Threads can do it, my approach can - potentially, too.

With native linux threading on kernel 2.6, I was able to create a few more
than 1000 tasks, by the way.

Regards,
Wojtek

Re: epoll Ada binding

[jn]

Wojtek Narczynski <wojtek@power.com.pl> wrote in message news:<pan.2004.10.19.07.51.40.40538@power.com.pl>...
> Hello,
> 
> > The goal for my programming exercise is to be able to handle 10 - 100
> > 000 concurrent connections effectively :).
> 
> I am currently working on a modified runtime that will use IO readiness
> for task scheduling. I have basic task switching working. I am able to
> create 10K tasks, but I don't know if it is going to work for 100K tasks,
> because of memory consumption. But my goal is to handle many connections
> maintaining the task-based way to program. Epoll is one of the bits I am 
> going to miss, so if your work will be Modified GPL, please talk to me.
> 
> Regards,
> Wojtek

Hello Wojtek,

we aim to provide a solution to the same problem space but our
approaches are dissimilar. My approach is to multiplex a number of
connections on the same task. The number of tasks should be related to
the number of CPUs (cores) on the machine. So for a machine with 4
dual-core CPUs I would chose 8 x N worker tasks. To cover for tasks
being blocked in file IO one could chose N=5 but one would really have
to test and measure to get N right.

Of course this approach requires the use of non-blocking IO and and
some event driven state machine for execution of the application. All
programming in the application space. Diving into the runtime sounds
exciting but is a bit advanced for me.

If and when I get a binding for 'epoll' ready I will let you know - I
have just started to think about 'epoll' after finding out limitations
in GNAT.Sockets implementation as well as in Linux if I were to use
'select'.

/jonas

Re: epoll Ada binding

[Wojtek Narczynski]

Hello,
 
> we aim to provide a solution to the same problem space but our
> approaches are dissimilar. My approach is to multiplex a number of
> connections on the same task. The number of tasks should be related to
> the number of CPUs (cores) on the machine. So for a machine with 4
> dual-core CPUs I would chose 8 x N worker tasks. To cover for tasks
> being blocked in file IO one could chose N=5 but one would really have
> to test and measure to get N right.

In my approach - as many processes, as there are CPUs. One task per socket
connection, task goes to sleep on read/write, until it can make progress.
Overall your solution will perform better because of potentially lesser
memory usage (each task needs at least two pages of stack), but I aim at
optimizing programmer productivity while maintaining good performance.
It's a bit like SGI State Threads.

> Diving into the runtime sounds exciting but is a bit advanced for me.

With nobody out there to help - major pain.

> If and when I get a binding for 'epoll' ready I will let you know - I
> have just started to think about 'epoll' after finding out limitations
> in GNAT.Sockets implementation as well as in Linux if I were to use
> 'select'.

You may want to take a look at PolyOrb code, there are event
demultiplexing goodies in there. The upper level design might be reusable.

Are your results going to be publically available? I am curious what the
complexity of EDSM solution will be.

Regards,
Wojtek

Re: epoll Ada binding

[jn]

Wojtek Narczynski <wojtek@power.com.pl> wrote in message news:<pan.2004.10.19.22.11.16.187438@power.com.pl>...
<snip> 
> You may want to take a look at PolyOrb code, there are event
> demultiplexing goodies in there. The upper level design might be reusable.
> 
> Are your results going to be publically available? I am curious what the
> complexity of EDSM solution will be.
> 
> Regards,
> Wojtek

Thanks for the tip. I only have some loose ideas around how to
implement the 'application' layer. I lean towards using an abstract
tagged type which is extended with session state and logic. Hopefully
it can be made really simple and easy to use :). I am also curious
what it really will look like and how well I succeed to encapsulate
the underlying complexity. This is the reason for my 'project'.

Yes, I will make it publically available if and when I have something
useful. Though, as you, I am doing this on my free time and I am
really a novice when it comes to Ada programming so don't expect
anything in the near time.

/jonas

Re: epoll Ada binding

[Florian Weimer]

* Mark Lorenzen:

> I think you have to write your own. But do you really need epoll? It
> is not POSIX compatable and only necessary when you have many (over
> 10000) concurrent connections.

epoll shows its effect far below the 10,000 concurrent connection
level.  It also allows for programming styles that are difficult to
replicate with other I/O multiplexing system calls.  For example, the
leader/followers pattern is in this category (IIRC).