comp.lang.ada
 help / color / mirror / Atom feed
From: Loren@cup.portal.com (Loren Louis Hart)
Subject: Re: Interpretation of LRM 13.10.1
Date: 27 Feb 90 19:47:53 GMT	[thread overview]
Message-ID: <27370@cup.portal.com> (raw)
In-Reply-To: D41AC33FCEFF000A65@KVI.nl

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

  parent reply	other threads:[~1990-02-27 19:47 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1990-02-23 15:48 Interpretation of LRM 13.10.1 "Fred Zwarts, KVI, Groningen, NL."
1990-02-27 15:50 ` Jerry Callen
1990-03-02 18:21   ` stt
1990-03-05 17:01     ` John Goodenough
1990-02-27 19:47 ` Loren Louis Hart [this message]
  -- strict thread matches above, loose matches on Subject: below --
1990-02-27 14:15 Mats Weber
1990-02-27 14:51 "Norman H. Cohen"
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox