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=3.8 required=5.0 tests=BAYES_00,INVALID_MSGID, RATWARE_MS_HASH,RATWARE_OUTLOOK_NONAME autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,7833e44c4d0da1bf,start X-Google-Attributes: gid103376,public From: "Jonas Nygren" Subject: Re: Task deallocation Date: 1997/02/23 Message-ID: <01bc2193$50d867c0$829d6482@joy.ericsson.se>#1/1 X-Deja-AN: 220850893 Organization: Ericsson Newsgroups: comp.lang.ada Date: 1997-02-23T00:00:00+00:00 List-Id: I sent out a question about how to deallocate dynamically allocated tasks. There were some answers from which I learnt that deallocating new'd tasks was perhaps not so straightforward as I believed. Apparently most compilers represents a task by a pointer to some internal structure. If this internal storage is not reclaimed when a task is deallocated one will have a storage leak. So my question is how to deallocate a dynamically allocated task without creating a memory leak. If I call Free for a dynamically allocated task will this ensure that the internal storage structures for tasks are reclaimed? E.g.: type My_Task_Ref is access My_Task; procedure Free is new Unchecked_Deallocation(My_Task, My_Task_Ref); MTR : My_Task_Ref := new My_Task; ... Free(MTR); -- assume MTR'Terminated is true -- will the internal task structures have been reclaimed?? or will it just reclaim the pointer that the compiler use to represent the instance of My_Task. My guess is that the example above will result in a storage leak. Mats Weber suggested that the only portable solution to handle deallocation of tasks is to put them on a global free-list instead of deallocating them. Is there really no portable way to deallocate dynamically allocated tasks without storage leaks? /jonas