comp.lang.ada
 help / color / mirror / Atom feed
From: Robert A Duff <bobduff@world.std.com>
Subject: Re: deallocation tasks
Date: 2000/05/04
Date: 2000-05-04T00:00:00+00:00	[thread overview]
Message-ID: <wccvh0u1nl3.fsf@world.std.com> (raw)
In-Reply-To: 8er87l$mo4$1@clnews.edf.fr

"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




  reply	other threads:[~2000-05-04  0:00 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-05-03  0:00 deallocation tasks Alfred Hilscher
2000-05-03  0:00 ` Robert A Duff
2000-05-04  0:00   ` Pascal Obry
2000-05-04  0:00     ` Robert A Duff [this message]
2000-05-05  0:00       ` Alfred Hilscher
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox