From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,adb9b9207aecb4b3 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!news.glorb.com!news.tele.dk!not-for-mail Sender: malo@0x535ba146.boanxx18.adsl-dhcp.tele.dk Newsgroups: comp.lang.ada Subject: Re: epoll Ada binding References: <311c6b78.0410181100.76f4e8ab@posting.google.com> <311c6b78.0410182103.110885b7@posting.google.com> From: Mark Lorenzen Date: 25 Nov 2004 01:22:17 +0100 Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Organization: TDC Totalloesninger NNTP-Posting-Host: 83.91.161.70 X-Trace: 1101342137 dtext02.news.tele.dk 165 83.91.161.70:55672 X-Complaints-To: abuse@post.tele.dk Xref: g2news1.google.com comp.lang.ada:6439 Date: 2004-11-25T01:22:17+01:00 List-Id: Wojtek Narczynski 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