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=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,e2e6547249e6f9d1
X-Google-Attributes: gid103376,public
From: "Norman H. Cohen" <ncohen@watson.ibm.com>
Subject: Re: How to wait for task completion
Date: 1996/09/18
Message-ID: <324060F8.46C8@watson.ibm.com>#1/1
X-Deja-AN: 181445735
references: <01bba4c8$a5ad67c0$2d208b82@wd>
 <DxxLKq.3BC.0.-s@inmet.camb.inmet.com>
content-type: text/plain; charset=us-ascii
organization: IBM Thomas J. Watson Research Center
mime-version: 1.0
reply-to: ncohen@watson.ibm.com
newsgroups: comp.lang.ada
x-mailer: Mozilla 3.0 (Win95; I)
Date: 1996-09-18T00:00:00+00:00
List-Id: <comp.lang.ada>


Tucker Taft wrote:

> The problem is that Ada 83 claimed that it was OK to free the task
> object associated with a task that was still running, and the task
> was not supposed to be affected.  We attempted to remain compatible
> with this rule, while also allowing more of the critical task information
> (e.g. the Task Control Block) to be held in the task object itself.
> These two rules led to task objects requiring special handling with
> respect to Free.
...
> The warning in 13.11.2(9) should have been replaced with a more carefully
> phrased "Implementation Permission."  As it is, it comes out of the blue,
> with no explanation, which is admittedly scary.

Perhaps this justifies implementation permission for attempted
deallocation
of a task object for an ACTIVE task to have no effect (as opposed, e.g.,
to
requiring the implementation to set a "deallocation-requested" flag in
the
task object, to check such flags upon task termination, and to perform
any
deferred deallocations at that time).

Unfortunately, 13.11.2(9) gives permission to ignore any deallocation of
a
task object (or of an object containing a task object), even if its task
has
terminated.  Thus the standard provides no way for a programmer
allocating 
task objects to ensure the absence of a storage leak.

I am aware of Ada-83 implementations that interpreted the note in
RM83-13.10.1(7) to mean that any attempt to deallocate a task object
--even for a terminated task--could simply be ignored.  (In my opinion,
this was a misinterpretation, based on a failure to distinguish between
the
terms "task" and "task object" in that paragraph--and a failure to
recall
that "Note" paragraphs are not part of the standard anyway!)  However,
upward compatibility with Ada 83 did not require preservation of this
behavior, since no program (intentionally) depends on a deallocation
that
it requested not taking place!

-- 
Norman H. Cohen    ncohen@watson.ibm.com    
                   http://www.research.ibm.com/people/n/ncohen