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-7-bit Path: g2news2.google.com!news2.google.com!newsfeed2.dallas1.level3.net!news.level3.com!bloom-beacon.mit.edu!newsswitch.lcs.mit.edu!nntp.TheWorld.com!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada Subject: Re: Delayed deallocation of non-terminated task in Gnat? Date: Wed, 31 Aug 2011 16:58:06 -0400 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: <31ba531d-fa8e-40f3-97bc-c9112b329fe2@14g2000prv.googlegroups.com> <1k4finucoux98.7be4jx6iy5kx$.dlg@40tude.net> <1upog8dc7hzkz$.wy4yj6fhgo40$.dlg@40tude.net> NNTP-Posting-Host: shell01.theworld.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: pcls6.std.com 1314824286 8664 192.74.137.71 (31 Aug 2011 20:58:06 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Wed, 31 Aug 2011 20:58:06 +0000 (UTC) User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (irix) Cancel-Lock: sha1:kVWJ+VMFk/mbcnjAOxTvqI1CmgA= Xref: g2news2.google.com comp.lang.ada:21772 Date: 2011-08-31T16:58:06-04:00 List-Id: "Dmitry A. Kazakov" writes: > Yes. If there exist terminate alternative, it must have a corresponding > entry. E.g. > > T'Terminate > > could denote the terminate entry of the task T. The semantics of the > rendezvous to T'Terminate is obvious, upon completion the callee is > terminated. It would be simple to introduce, IMO. Simple to introduce from a semantics point of view, and useful, but rather tricky to implement, for the same reasons that the feature we're discussing (avoiding the storage leak) is tricky. If a task itself notices that it is about to terminate, and therefore frees resources (the task control block, the task stack), it is running while it's doing that stuff, and it's tricky to make sure it doesn't use those resources after they're freed. E.g., the free wanted to defer/undefer aborts, which involves touching the task control block, which is being freed! We figured out how to do it, and it wasn't a lot of code, but it was very subtle code. >> or a group of tasks. > > There is no rendezvous to multiple tasks or calls to multiple entry points > (of several protected objects). That was proposed for Ada 9X. >... It could be useful but the semantics is > unclear. As I recall, there was both "and" and "or" semantics. So in the context of termination, that would give you "wait until all these tasks are terminated", and "wait until one of these tasks is terminated (and tell me which one)". >> I'm not sure U_D should be that feature, though, >> because then it would only work for access-to-task(s). > > It certainly should. The behavior of an object may not depend on the way it > was allocated. Since deallocation of a task on the stack is effectively > blocking, so its deallocation using Unchecked_Deallocation should be. I see > no use in a non-blocking Unchecked_Deallocation. Maybe you're right, I'm not sure. I think it does make sense to fire up a task, and have it get freed on termination, with no particular other task waiting for that termination. The U_D you want, that waits for termination, can be written in terms of the mythical "await termination" primitive we discussed above, and the existing Ada U_D that does not wait. - Bob