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!rutgers!usc!zaphod.mps.ohio-state.edu!uwm.edu!bionet!agate!ucbvax!vma.cc.cmu.edu!madmats%elcit.epfl.ch From: madmats%elcit.epfl.ch@vma.cc.cmu.edu (Mats Weber) Newsgroups: comp.lang.ada Subject: Interpretation of LRM 13.10.1 Message-ID: <900227151553.20200c99@SIC.Epfl.CH> Date: 27 Feb 90 14:15:53 GMT Sender: usenet@ucbvax.BERKELEY.EDU Organization: The Internet List-Id: >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. It is the right place to ask. >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 LRM says nothing about the deallocation of the working storage (stack space, etc.) of tasks. Most implementations I know of reclaim that storage when the block that declares the corresponding task type is left, but this behaviour is not required by the LRM. "no effect" means that calling Free(X) does not affect the execution of the designated task, in particular, the designated task does not stop and must still terminate before its master can be exited. Free(X) simply makes the designated task inaccessible. >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. You are right. Most implementations do not reclaim the stack storage of terminated tasks. A workaround is to put these unused tasks into a pool and reuse them, allocating new tasks only when the pool is empty. Mats Weber Swiss Federal Institute of Technology EPFL DI LGL 1015 Lausanne Switzerland E-mail : madmats@elcit.epfl.ch phone : +41 21 693 52 92 fax : +41 21 693 22 20