"Adam Beneschan" <adam@irvine.com> wrote in message 
news:bf5f741b-8ced-4530-8090-df6d4e730a5e@e2g2000vbb.googlegroups.com...
>On Nov 22, 9:04 pm, Yannick Duch�ne (Hibou57)
<yannick_duch...@yahoo.fr> wrote:
>> Le Wed, 23 Nov 2011 03:44:39 +0100, Adam Beneschan <a...@irvine.com> a
>> �crit:> The language rules say that Unchecked_Deallocation doesn't force 
>> tasks
>> > to terminate.
>>
>> But it should, because unless I missed something, it seems in this 
>> example
>> case at least, this lead to a dangling reference.
>
>*Any* use of Unchecked_Deallocation can lead to a dangling reference,
>which is why it's called Unchecked.  But also note that the language
>explicitly says that if you use Unchecked_Deallocation on an object
>that contains tasks, the object might not actually disappear
>(13.11.2(9)).  I'm not sure if there are language rules that say that
>the object *must* not be deallocated immediately in a case like this,
>where the task has a discriminant that refers to the object being
>freed.  I don't have time to look into it at the moment.  Maybe
>someone else knows?

The task continues to run (always) through a UC. The compiler has to ensure 
that works, and if that means not deallocating the object, that would work. 
Janus/Ada doesn't work this way, all of the task information is in the TCB 
and there is no connection to the enclosing object. So we can deallocate it 
immediately - the task will still continue to work. TCBs are reused when the 
tasks terminate, and never before.

The requirement that tasks continue to run means that putting a task 
directly in an object will typically lead to a language-required storage 
leak. I always suggest avoiding that. (All of my programs that use tasks use 
fixed pools of tasks that reset themselves after use, in large part because 
tasks can't be managed like other objects.)

One could argue that this behavior is a bug in the Ada Standard (I've 
certainly said that in the past), but there are a number of technical 
reasons that doing something else would be problematical. And changing it 
now would definitely be incompatible - any program that depends on the task 
continuing to run would fail (and in the worst possible way - without any 
indication of the change). We tried to do something else for subpools, but 
the implementation costs were out of hand, and essentially we decided to 
punt (the behavior of tasks in subpools is unspecified) -- hoping to fix 
this somewhere down the line.

                                              Randy.


                           -- Adam