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,89cbee942992178a,start
X-Google-Attributes: gid103376,public
From: "Jonas Nygren" <ehsjony@ehs.ericsson.se>
Subject: Deallocating Task objects
Date: 1997/02/15
Message-ID: <01bc1b53$fb0251c0$829d6482@joy.ericsson.se>#1/1
X-Deja-AN: 218984790
Organization: Ericsson
Newsgroups: comp.lang.ada
Date: 1997-02-15T00:00:00+00:00
List-Id: <comp.lang.ada>



I sent out a question to c.l.a about how to reclaim memory for tasks
that are dynamically allocated. Since then I have been trying to find 
some 'nice' way of doing this.

I have identified one sentence in the Ada RM that seems to provide
some sort of automatic storage reclamation. The sentence is found in 
13.11(18) and reads:

"If Storage_Size is specified for an access type, then the Storage_Size 
 of this pool is at least that requested, and the storage for the pool 
 is reclaimed when the master containing the declaration of the access 
 type is left."

This seems to provide some sort of 'garbage collection'. One have
to give an upper bound on the number of allocatable objects but this is
quite acceptable for my code.

I wonder if somebody can confirm that my interpretation of this sentence
is correct. Below I have attached a small tasking example with one
Main_Task that dynamically allocates Sub_Tasks and I want to be absolutely 
sure that the storage used for the Sub_Tasks have been reclaimed when the
Main_Task instance, A_Main_Task, goes out of scope.

Have I interpreted the 13.11(18) sentence correctly? Is the construct 
portable between different Ada compilers?

/jonas

PS of course I could have defined an array of Sub_Tasks instead but then
   there would have been the added complexity of synchronizing the
Main_Task's
   stack size with the number of allocated Sub_Tasks. DS

PPS I have tried this with Gnat 3.09 for NT and Win95 and it will only
handle
    a maximum of 57 Sub_Tasks. With 58, or more, Sub_Tasks it will just
hang 
    in the allocator, without any errors. I will report this bug to ACT.
DDS

-- code follows

with Text_IO;
procedure Test is
   task type Main_Task (Max_Sub_Tasks : Positive);

   task body Main_Task is

      task type Sub_Task is
         entry Dummy;
      end Sub_Task;

      type Sub_Task_Ref is access Sub_Task;
      for Sub_Task_Ref'Storage_Size use Max_Sub_Tasks * Sub_Task'Size; --
13.11(18)

      task body Sub_Task is
      begin
         loop
            select
               accept Dummy;
            or
               terminate;
            end select;
         end loop;
      end Sub_Task;

      A_Sub_Task : Sub_Task_Ref;
   begin
      for I in 1..Max_Sub_Tasks loop
         A_Sub_Task := new Sub_Task;
	  Text_IO.Put_Line(Integer'Image(I));
      end loop;

      delay 1.0;
   end Main_Task;
begin
   declare
      A_Main_Task : Main_Task(1000);
   begin
      null;
   end;
   -- at this point all storage allocated for Sub_Task objects
   -- in A_Main_Task will have been reclaimed
end Test;