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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,ea9fbf0f08e5af8a X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII Path: g2news1.google.com!postnews.google.com!w22g2000prj.googlegroups.com!not-for-mail From: Adam Beneschan Newsgroups: comp.lang.ada Subject: Re: Delayed deallocation of non-terminated task in Gnat? Date: Wed, 31 Aug 2011 09:39:08 -0700 (PDT) Organization: http://groups.google.com Message-ID: References: <31ba531d-fa8e-40f3-97bc-c9112b329fe2@14g2000prv.googlegroups.com> NNTP-Posting-Host: 66.126.103.122 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1314810427 12077 127.0.0.1 (31 Aug 2011 17:07:07 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Wed, 31 Aug 2011 17:07:07 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: w22g2000prj.googlegroups.com; posting-host=66.126.103.122; posting-account=duW0ogkAAABjRdnxgLGXDfna0Gc6XqmQ User-Agent: G2/1.0 X-Google-Web-Client: true X-Google-Header-Order: ARLUEHNKC X-HTTP-UserAgent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; WOW64; Trident/4.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.5.21022; .NET CLR 3.5.30729; .NET CLR 3.0.30618; .NET4.0C),gzip(gfe) Xref: g2news1.google.com comp.lang.ada:20792 Date: 2011-08-31T09:39:08-07:00 List-Id: On Aug 30, 8:38=A0am, Adam Beneschan wrote: > I think this is right---the task continues to function until it > terminates. =A0The only way to get a task to stop executing before it > completes is to abort it (via an abort statement, or other semantics > that cause an abort---see 9.8). =A0An Unchecked_Deallocation instance > finalizes the task object, but the semantics of finalization don't > involve aborting. =A0I'm having a bit of difficulty figuring out from > the RM what the exact semantics of finalizing an unterminated task > object are, but I'm pretty sure that aborting the task is not one of > them. Actually, I just found this in the Ada 83 manual (13.10.1(8)): "If X designates a task object, the call FREE(X) [where FREE is an instance of Unchecked_Deallocation] has no effect on the task desginated by the value of the task object. The same holds for any subcomponent of the object designated by X, if this subcomponent is a task object." This language got dropped in Ada 95, but I think it was intended that these still be the semantics, for a task without discriminants (Ada 83 did not allow task discriminants). I'm not sure why the language was omitted; it could have just been inadvertent (I've seen one or two other cases where RM83 language got lost and left some things undefined that should have been defined), or the authors could have felt that it was no longer necessary because of other wording changes, particularly those dealing with finalization. The latter could be correct, although I've been having trouble finding RM language that made it clear that this was supposed to happen. The current RM does say that "if the object being freed contains tasks, the object might not be deallocated", but this doesn't clearly say anything about what happens to the task. One thing that bothers me a bit, although I don't know if it bothers me enough to request an RM change: 13.11.2(10) says that after Free(X), the designated object and its subcomponents no longer exist. 9.1(15-18) says that the content of a task object includes entry queues for the task. I'm willing to accept that there is a distinction between a task object and a task (or a task execution), but if the task object no longer exists, does that mean that the entry queues that it contains no longer exist, and that therefore if another task Y was waiting on X.all's entry when X was freed, so that the entry queue on which Y was sitting no longer exists, does Y's entry call get cancelled? Again, I don't think this is the intent, but I'm not sure. -- Adam