Re: Server - tasking and long lived connections

["Pat Rogers" <progers@classwide.com>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1535 bytes --]


"Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message
news:YaH+t3eYcXsB@eisner.encompasserve.org...
> In article <9vkecb$a6v$1@s1.read.news.oleane.net>, "Jean-Pierre Rosen"
<rosen@adalog.fr> writes:
> >
> > "Thierry Lelegard" <thierry.lelegard@canal-plus.fr> 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