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.8 required=5.0 tests=BAYES_00,INVALID_DATE
	autolearn=no autolearn_force=no version=3.4.4
Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!sun-barr!newstop!sun!imagen!atari!portal!portal!cup.portal.com!Loren
From: Loren@cup.portal.com (Loren Louis Hart)
Newsgroups: comp.lang.ada
Subject: Re: Interpretation of LRM 13.10.1
Message-ID: <27370@cup.portal.com>
Date: 27 Feb 90 19:47:53 GMT
References: <D41AC33FCEFF000A65@KVI.nl>
Organization: The Portal System (TM)
List-Id: <comp.lang.ada>

In his artical about LRM 13.10.1 Fred Zwarts writes:
>Hello all,

>I am rather new to Ada and I am not quite sure that this is the right place to
>ask, but I do not know a better place.

This is exactly the right place for this question.  It is much better than the
"My language is better than your language" discussion that has been apearing
in this news group lately.

>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?

Has no effect means exactly what it says.  The program behaves the same in all
respects if it is there or not.  It will be the same (other than maybe
efficiency) as if the compiler generated no code.  My understanding is that
a task is an object, you can deallocate objects, it is potentially confusing
and dangerious to allow someone to deallocate a task.  The choice is either to
ignore the request or generate an error; in this case they decided the 
request should be ignored.

>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 leas
t
>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.

Most implementations (all that I know about) deallocate all of the memory
that a task uses upon termination.  The only exception is sometimes the
fairly small entry for that task that indicates if the task is running and
where to find its memory is kept around.

Loren L. Hart
loren@cup.portal.com
San Jose, California