Re: Deallocating Task objects

[dewar@merv.cs.nyu.edu (Robert Dewar)]

Bob Duff said

<<The case is where a function returns a task object that is local to the
function.  I believe there was an Ada 83 AI that "clarified" that this
case was erroneous, so that storage for the task could be deallocated
upon leaving the function.  (In the standards business, "clarified" is a
euphemism for "fixing a bug in the language".  ;-))  Unfortunately, this
fix was made after ACVC tests had already forced implementers to keep
that storage around.

In Ada 95, this case raises Program_Error.  The error can actually be
caught at compile time, except in some cases involving generics -- a
good compiler will warn at compile time.>>



The history is not quite right, and is interesting. The Ada 83 RM does
indeed imply (but a not entirely obvious chain of reasoning), that a
function can return a local task, and the caller can check if it is
terminated. 

Jean Pierre Rosen noticed this and considered it an obvious bug in the
design. Confident that the ARG would fix this, he submitted it as an
issue. Amazingly, the ARG voted that this behavior was intended and
must be required. The consequence is awful, the only reasonable
implementation is to keep tasks around much longer than is needed.

At the following meeting of WG9, Jean Ichbiah and I launched an energetic
attempt to convince WG9 that this was NOT one of the ARG decisions that
should be approved. We lost, largely because Ron Brender of Digital
announced that this could be implemented without any negative impact.
(An ironic claim, since in fact the way that Digital reacted to this
ruling, like other vendors, was to delay freeing of locally allocated
tasks in this situation.

The ACVC suite, in the business of enforcing ARG decisions, then produced
tests that required this to work (how any one could possibly think this
was useful is beyond me). Implentors dutifully implemented it (at least
in the case of Digital and Alsys, this was done simply by not freeing
tasks completely in this situation, causing an annoying storage leak).

Much later, the ARG visited this issue, and declared that this situation
was pathological, which meant that no compiler was expected to implement
it (I do not remember if it was formally declared erroneous or not, I
don't have my AI's with me right now). This meant that the test was
challengable, but in fact, to my memory it did not get challenged, since
this was late in the Ada 83 cycle.

Finally, it was fixed, in a rather nice and general way in Ada 95.

Anyone want to add to or amend this bit of history (trying to remember
things from this far back in detail is always a bit unreliable :-)