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=0.7 required=5.0 tests=BAYES_00,INVALID_DATE,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
Path: utzoo!attcan!uunet!aplcen!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!uwm.edu!psuvax1!husc6!encore!jcallen
From: jcallen@Encore.COM (Jerry Callen)
Newsgroups: comp.lang.ada
Subject: Interpretation of LRM 13.10.1
Summary: Trust the RTS
Message-ID: <11249@encore.Encore.COM>
Date: 27 Feb 90 15:50:42 GMT
References: <D41AC33FCEFF000A65@KVI.nl>
Reply-To: jcallen@encore.com (Jerry Callen)
Organization: Encore Computer Corp, Marlboro, MA
List-Id: <comp.lang.ada>

In article <foo> F.Zwarts@KVI.NL ("Fred Zwarts, KVI, Groningen, NL.") writes:

>I am uncertain about the interpretation of LRM 13.10.1(8) on the
>UNCHECKED_DEALLOCATION procedure, where I read:
>
>"If X designates a task object, the call FREE(X) has no effect on the task
>...".
>
>My question is: What means "no effect"?
>Suppose X designates a terminated task, see LRM 9.4(6-10).
>Can FREE(X) be used to reclaim memory held by such a terminated task, like a
>task control block? Does the LRM allow such an interpretation?

The "no effect" statement means that freeing a task object won't do
something unpleasant to it (like free its stacks/control blocks out from
under it).

You can't really reclaim ALL of the storage associated with a task until the
task's scope disappears, even in the case of a task created with an allocator;
there may be other copies of the pointer floating around, and the owners of
those copies may (erroneously) query the 'CALLABLE/'TERMINATED attributes
of the task. You could argue that, by using Unchecked_Deallocation, you are
explicitly telling the RTS that there are no dangling pointers, but I
think it's safer for the RTS to assume that there might be. Note that a
clever implementation will release nearly all of the storage associated with
a task (stacks, most control blocks, etc.) at task completion; all that really
has to hang around is a stub of the TCB that can be used to implement the
above attributes.

>If this interpretation is not allowed, I can imagin a case in which one runs
>out of memory because of a large amount of terminated tasks. If always at least
>one such task is running, it is not possible to leave the block in which the
>declaration of X's type was elaborated LRM 9.4(6), which could otherwise be a
>way to reclaim memory.

Hopefully your RTS is going to free as much storage as it can at task
completion. Trying to "help it" with Unchecked_Deallocation is probably
useless.

>Fred Zwarts                             E-mail:         INFOADA@KVI.nl
>Kernfysisch Versneller Instituut
>9747 AA  Groningen
>The Netherlands

-- Jerry Callen
   jcallen@encore.com
   (508) 460-0500