Re: DYNAMIC ADA TASK CREATION?

["Robert I. Eachus" <rieachus@attbi.com>]

Simon Wright wrote:

>>>:     type ts is array (positive range <>) of ta := new t;
>>>                                                ^^^^^^^^  

> That version was Robert's ...

Let me make it official, it was a typo, should have been:

   type ts is array (positive range <>) of ta := (others => new t);

But I really wanted to answer this:

   Oh, why is it worse with discriminants?

There are usually in Ada implementations two types of storage associated 
with tasks.  The first is a task descriptor, which contains addresses 
for the code, entry queues, and other such stuff.  The other part is a 
stack and (and possibly local heap) for the executing object.  If the 
task has descriminants, they are normally stored in the task descriptor. 
Again in the normal case, the stack (and local heap if allocated) will 
be deallocated when the task terminates.  The task descriptor is the 
thing that can be deallocated by Unchecked_Deallocation.

If a task without discriminants is freed before it becomes terminated, 
it won't affect the executing task.  But it may deallocate the task 
descriptor which contains the discriminants.  If the task, or any of 
it's dependent tasks references the discriminants, it is a bounded 
error, which will most likely cause Program_Error in the task.  See RM 
13.11.2(11-15) for details on other possibilities.

For a task without discriminants, you may not free all the memory that 
you had hoped for, but the only real effect is that you may no longer be 
able to reference the task.  (Of course, calling an instance of 
Unchecked_Deallocation while salting away a copy of the pointer is not 
something you should do either.  But that case is a lot more obvious.)

In most normal tasking programs there is no particular reason to free 
the task descriptors.  And as I said, the memory allocated for the stack 
will go away anyway when the task is terminated.  (In language lawyer 
speak, a task is completed when the code execution reaches the end of 
the code and in other cases.  But termination waits until all dependent 
tasks have become terminated.  This is so that dependent tasks can still 
reference the parent task's stack.)

So usually when a programmer thinks he wants to go around stomping out 
tasks, he has left one or two tasks hanging that are keeping a lot of 
other tasks half-alive.