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: a07f3367d7,c33f8f65997c21d0 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.224.70.131 with SMTP id d3mr7526749qaj.0.1348505038566; Mon, 24 Sep 2012 09:43:58 -0700 (PDT) Received: by 10.236.198.80 with SMTP id u56mr1194176yhn.0.1348505038533; Mon, 24 Sep 2012 09:43:58 -0700 (PDT) Path: e10ni13434282qan.0!nntp.google.com!l8no8454628qao.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Mon, 24 Sep 2012 09:43:58 -0700 (PDT) In-Reply-To: <697f51fe-6971-477a-bf50-cb1b12c792d9@googlegroups.com> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=66.126.103.122; posting-account=duW0ogkAAABjRdnxgLGXDfna0Gc6XqmQ NNTP-Posting-Host: 66.126.103.122 References: <1667b8e2qt7ei$.1gg1h3hrp9amz$.dlg@40tude.net> <187uk10m6z8xj.yr1cpbgrdur$.dlg@40tude.net> <697f51fe-6971-477a-bf50-cb1b12c792d9@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: Problem with task component From: Adam Beneschan Injection-Date: Mon, 24 Sep 2012 16:43:58 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: 2012-09-24T09:43:58-07:00 List-Id: On Monday, September 24, 2012 9:13:12 AM UTC-7, AdaMagica wrote: > On Monday, September 24, 2012 5:44:32 PM UTC+2, Adam Beneschan wrote: >=20 > > I've been trying to think of a way to get around the "forget" problem b= y using controlled types. My first thought was to define a controlled reco= rd (i.e. derived from Ada.Finalization.Limited_Controlled) that has a task = as a component, and have the Finalize routine for the controlled type call = the Shutdown entry. That way, since the shutdown protocol would be defined= , in essence, right by the definition of the task type, there's no way a pr= ocedure that uses the type could "forget" to call Shutdown. No good, thoug= h; 7.6.1(4) says that the Finalize routine on the record object would be ca= lled *after* the task terminates. So it would be too late. >=20 >=20 >=20 > Why not use abort in this case? (In the general case, abort might not wor= k immediately or be dangerous, but under these circumstances? I used it e.g= . effectively when a commercial flight simulator program - all tasks inside= have infinite loops - had to be stopped.) It wouldn't solve the problem. Using a Shutdown entry, and requiring that = the master call it before it leaves, seems to be the best solution, but the= issue is that it requires the master to call the entry, and a coder could = forget that (or they could put the Shutdown call at the end of the block bu= t then sabotage themselves by putting a RETURN statement in the middle of t= he code sequence). Using an abort statement is no better.=20 -- Adam