Re: How-to on using the adacl-gc packages

[Simon Wright <simon@pushface.org>]

"Martin Krischik" <krischik@users.sourceforge.net> writes:

> I know at least one memory allocation problem where I have not yet
> found a solution for - no matter how much engineering I have put into
> the problem:
>
> task type T;
> type T_Access is access T;
>
> ...
>
> X : T_Access := new T;

What I do in ColdFrame is (with a bit of concatenation and elision)

   type Instance (<>)
   is new ---- with private;
   type Handle is access all Instance;

private

   task type T (This : access Instance) is
      -----
      entry -----;
   end T;
   type T_P is access T;
   procedure Free is new Ada.Unchecked_Deallocation (T, T_P);

   type Instance is new ----- with record
      The_T : T_P;
      -----
   end record;

   procedure Free is new Ada.Unchecked_Deallocation (Instance, Handle);

   procedure Delete (This : in out Handle) is
      -----
   begin
      -----
      abort This.The_T.all;
      Free (This.The_T);
      -----
      Free (This);
   end Delete;

which has caused us no problems (GNAT, NT, Linux, MacOS, VxWorks)[1];
but I'm always prepared to be told I'm wrong.

A while back AdaCore pointed me towards LRM 13.11.2(9):

   Free(X), when X is not equal to null [...] deallocates the storage
   occupied by the object designated by X. [...] There is one
   exception: if the object being freed contains tasks, the object
   might not be deallocated.

It's not clear to me quite what 'contains tasks' means. From a
position of ignorance, I could argue that The_T.all doesn't _contain_
a task, it _is_ a task.

> The last I read only recently here was: task types are small - don't
> bother deallocating them. Anybody got any better advice?

It all depends how often you do it and what your platform's memory
availability is! On VxWorks (5.4, PowerPC) you are stuck with the
physical memory ...


[1] except when people called Delete from the task that was to be
deleted. I catch this now.