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=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,622a39829f542d91
X-Google-Attributes: gid103376,public
From: Robert A Duff <bobduff@world.std.com>
Subject: Re: deallocation tasks
Date: 2000/05/04
Message-ID: <wccvh0u1nl3.fsf@world.std.com>#1/1
X-Deja-AN: 619126275
Sender: bobduff@world.std.com (Robert A Duff)
References: <39102BF9.584EB022@icn.siemens.de> <wccbt2nln7v.fsf@world.std.com>
 <8er87l$mo4$1@clnews.edf.fr>
Organization: The World Public Access UNIX, Brookline, MA
Newsgroups: comp.lang.ada
Date: 2000-05-04T00:00:00+00:00
List-Id: <comp.lang.ada>

"Pascal Obry" <p.obry@der.edf.fr> writes:

> I'am not sure to understand the point here! Why is it not safe to call
> Unchecked_Deallocation on a task with discriminants ?

In a typical implementation, a task object is represented as a chunk
of memory containing the discriminants, plus a pointer to a Task Control
Block (TCB).  When U_D is called, that chunk of memory is deallocated,
but the TCB remains, and the task keeps running.  If there are no
discrims, the task is happy.  But if there are discrims, and the task
itself refers to them, they're gone -- the task is referring to a
nonexistent object, which is a Bad Thing.

Aside: In the no-discrims case, a task object is just a pointer to the
TCB.  So an access-to-task object is a pointer to a pointer to a TCB.
However, because task types are limited, the implementation can optimize
away one level of indirection -- it can implement an access-to-task
exactly as a task object.

Other implementations are possible.  In Ada 95 (but not Ada 83), a task
object could contain the TCB, rather than a pointer to it.

- Bob