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.1 required=5.0 tests=BAYES_00, PP_MIME_FAKE_ASCII_TEXT autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII X-Google-Thread: 103376,fed2e7871ca258cd X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-12-17 07:40:10 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news.tele.dk!small.news.tele.dk!207.115.63.138!newscon04.news.prodigy.com!newsmst01.news.prodigy.com!prodigy.com!postmaster.news.prodigy.com!newssvr30.news.prodigy.com.POSTED!not-for-mail From: "Pat Rogers" Newsgroups: comp.lang.ada References: <3C1DB7B7.DF767F9@canal-plus.fr> <9vkecb$a6v$1@s1.read.news.oleane.net> Subject: Re: Server - tasking and long lived connections X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: <7loT7.321$TH6.104956948@newssvr30.news.prodigy.com> NNTP-Posting-Host: 208.191.176.121 X-Complaints-To: abuse@prodigy.net X-Trace: newssvr30.news.prodigy.com 1008603587 ST000 208.191.176.121 (Mon, 17 Dec 2001 10:39:47 EST) NNTP-Posting-Date: Mon, 17 Dec 2001 10:39:47 EST Organization: Prodigy Internet http://www.prodigy.com X-UserInfo1: FKPO@MC@OXRQRILY@BJZ\_TDFRYB@GXLN@GZ_GYO^BTBTSUBYFWEAE[YJLYPIWKHTFCMZKVMB^[Z^DOBRVVMOSPFHNSYXVDIE@X\BUC@GTSX@DL^GKFFHQCCE\G[JJBMYDYIJCZM@AY]GNGPJD]YNNW\GSX^GSCKHA[]@CCB\[@LATPD\L@J\\PF]VR[QPJN Date: Mon, 17 Dec 2001 15:39:47 GMT Xref: archiver1.google.com comp.lang.ada:18008 Date: 2001-12-17T15:39:47+00:00 List-Id: "Larry Kilgallen" wrote in message news:YaH+t3eYcXsB@eisner.encompasserve.org... > In article <9vkecb$a6v$1@s1.read.news.oleane.net>, "Jean-Pierre Rosen" writes: > > > > "Thierry Lelegard" a �crit dans le message news: 3C1DB7B7.DF767F9@canal-plus.fr... > >> 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). > >> > > This was due to the (in)famous Rosen's pathology ;-) > > It has been (fortunately) exterminated in in Ada 95, so the problem should not appear any more. > > Does the standard mandate that such a problem not happen, > or simply avoid mandating something that would force it to happen? It is solved indirectly because functions can no longer return limited types (eg task types) by-value. (A nice simple rule that solves a number of issues.) --- Patrick Rogers Consulting and Training in: http://www.classwide.com Real-Time/OO Languages progers@classwide.com Hard Deadline Schedulability Analysis (281)648-3165 Software Fault Tolerance