Re: Class with task destructor

[Adam Beneschan <adam@irvine.com>]

On Nov 23, 4:15 pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
>
> >*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.

Except that in the OP's case, there *is* a connection: the task has an
access discriminant that will refer to the enclosing object, and if
the task keeps running, it could use that discriminant.  That's what I
wanted to know--in a case like that, are there language rules that say
the object can't be deallocated until the task has completed; or does
the access discriminant just become a dangling reference?  Or does
Janus/Ada (or any other compiler) treat cases like this specially so
that the access discriminant is still valid?  Since
Unchecked_Deallocation is always capable of creating dangling
references, maybe this case isn't so special; I was just wondering
whether this is a special case at all, since off the top of my head it
seems that objects that contain self-references through access
discriminants can't lead to dangling references (through those self-
references) when the objects are deallocated, *unless* they involve a
task that keeps running as in this case.

                        -- Adam