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,e2e6547249e6f9d1 X-Google-Attributes: gid103376,public From: stt@houdini.camb.inmet.com (Tucker Taft) Subject: Re: How to wait for task completion Date: 1996/09/18 Message-ID: #1/1 X-Deja-AN: 181383077 sender: news@inmet.camb.inmet.com (USENET news) x-nntp-posting-host: houdini.camb.inmet.com references: <01bba4c8$a5ad67c0$2d208b82@wd> organization: Intermetrics, Inc. newsgroups: comp.lang.ada Date: 1996-09-18T00:00:00+00:00 List-Id: wiljan (W.Derks@nl.cis.philips.com) wrote: : Norman H. Cohen wrote in article : <51mhns$jif@watnews1.watson.ibm.com>... : > Indeed, RM95-C.7.2(17) guarantees this. However, unlike Ada 83, Ada 95 : > does not guarantee that unchecked deallocation will reclaim the storage : > for a task object (or for a composite object with a subcomponent that is : > a task object), even if the task has terminated when the deallocation : > procedure is called! See the last sentence of RM95-13.11.2(9). : > : > I hope none of the implementors has read this sentence. :-) : Incredible. I think here is a point to look at in the next Ada standard. : Thanks for pointing me to the locations in the RM. Not surprisingly, there is a bit of history behind this one. 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. In my view, the preferred rule would be that Program_Error is raised if you try to free a task object if the task is not yet terminated, but alas that would not be upward compatible in general. In fact, we allow Program_Error for tasks with discriminants (RM95 13.11.3(13)), since there is no upward compatibility issue for such tasks (Ada 83 tasks couldn't have discriminants). 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. : Wiljan -Tucker Taft stt@inmet.com http://www.inmet.com/~stt/ Intermetrics, Inc. Cambridge, MA USA