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,4bd6ca8f7a1eb225 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.68.15.105 with SMTP id w9mr75857pbc.7.1322700093589; Wed, 30 Nov 2011 16:41:33 -0800 (PST) MIME-Version: 1.0 Path: lh20ni47737pbb.0!nntp.google.com!news1.google.com!goblin1!goblin.stu.neva.ru!news.tornevall.net!news.jacob-sparre.dk!pnx.dk!jacob-sparre.dk!ada-dk.org!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Class with task destructor Date: Wed, 30 Nov 2011 18:40:09 -0600 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <30604696.94.1322013045135.JavaMail.geo-discussion-forums@yqzz20> <24938373.1788.1322615481874.JavaMail.geo-discussion-forums@yqjo5> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1322700011 5521 69.95.181.76 (1 Dec 2011 00:40:11 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Thu, 1 Dec 2011 00:40:11 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Xref: news1.google.com comp.lang.ada:19274 Date: 2011-11-30T18:40:09-06:00 List-Id: "Robert A Duff" wrote in message news:wcc39d5in9z.fsf@shell01.TheWorld.com... > Adam Beneschan writes: ... >> Is it just me, or are there others who think that resorting to code >> like this is ... well, icky? > > It's not just you. ;-) > > Ada should provide a way to wait for an arbitrary task, or a group of > tasks, > to terminate. Without polling. It's quite tricky to implement, though. Of course, when we tried to do that for subpools, AdaCore complained loudly, and we ended up taking that feature out of the subpool proposal. The problem is that waiting on multiple events is not something that is easily done, and it is especially hard to insert into existing task supervisors (designed without needing to do that). I thought (and still think) that some sort of sub-master would do the trick without too much disruption, but the feedback we got on that idea was not too positive. Anyway, it would make sense to have a much more general feature rather than worrying about this problem only in the context of Unchecked_Deallocation and Unchecked_Deallocate_Subpool. But that will be even a harder sell, I fear. Randy.