Re: epoll Ada binding

[Mark Lorenzen <mark.lorenzen@ofir.dk>]

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