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 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,fed2e7871ca258cd X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-12-17 01:20:03 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!dispose.news.demon.net!demon!grolier!oleane.net!oleane!nnrp.oleane.net!not-for-mail From: Thierry Lelegard Newsgroups: comp.lang.ada Subject: Re: Server - tasking and long lived connections Date: Mon, 17 Dec 2001 10:15:35 +0100 Organization: CANAL+ Technologies Message-ID: <3C1DB7B7.DF767F9@canal-plus.fr> References: NNTP-Posting-Host: host227.canal-plus.fr Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: s1.read.news.oleane.net 1008580536 9599 194.2.208.227 (17 Dec 2001 09:15:36 GMT) X-Complaints-To: abuse@oleane.net NNTP-Posting-Date: Mon, 17 Dec 2001 09:15:36 +0000 (UTC) X-Sender: "Thierry Lelegard" (Unverified) X-Mailer: Mozilla 4.78 [fr]C-CCK-MCD C+ (WinNT; U) X-Accept-Language: en,fr,zh-CN,zh-TW Xref: archiver1.google.com comp.lang.ada:17988 Date: 2001-12-17T10:15:35+01:00 List-Id: We have applications that we successfully tested with up to 6000 tasks. That was on OpenVMS with the DEC Ada compiler. We now use GNAT on VMS/UNIX/WNT. We haven't yet made such load testing but several hundredths of tasks run fine. On most operating systems, though, this requires some tuning (memory management, I/O, etc). I think that the trap in this kind of applications (servers with one or more tasks per client connection) is the fate of the tasks when the client disconnects. If you let the tasks die and recreate new tasks for new client connections, you will most certainly face some slow memory leak. We have seen that, although the stack itself is deallocated when a task dies, there aer a few bytes which remain allocated (some kind of TCB I suppose). So, the trick is to never let the service tasks die. When a client disconnects, just queue the service task for future usage by a new client connection. When a new connection comes in, reuse an idle service task. Create a new one only when there is no available idle task. Of course, if you connection are long lived (several hours) and your application is relatively short lived (a few weeks), this may not be an issue. But if you want your application to potentially run forever, you should take care. In the (long) past, I have seen a Minitel server (French ancestor of the WWW) crashing every 3 months, due to virtual memory exhaustion, just because the Ada tasks died when the clients disconnected. -Thierry ____________________________________________________________________________ Thierry Lelegard, "The Jazzing Troll", Email: thierry.lelegard@canal-plus.fr CANAL+ Technologies, 34 place Raoul Dautry, 75906 Paris Cedex 15, France Tel: +33 1 71 71 54 30 Fax: +33 1 71 71 52 08 Mobile: +33 6 03 00 65 75 ____________________________________________________________________________