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=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!nntp-feed.chiark.greenend.org.uk!ewrotcd!newsfeed.xs3.de!io.xs3.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED.rrsoftware.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Finalization of library level tasks Date: Thu, 26 Apr 2018 17:10:39 -0500 Organization: JSA Research & Innovation Message-ID: References: <702e2422-a93f-4200-9749-5122c3d0f899@googlegroups.com> <04f19a56-7fab-416e-8ec0-b9a73e239e90@googlegroups.com> Injection-Date: Thu, 26 Apr 2018 22:10:41 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="2397"; mail-complaints-to="news@jacob-sparre.dk" X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246 Xref: reader02.eternal-september.org comp.lang.ada:51733 Date: 2018-04-26T17:10:39-05:00 List-Id: "Dmitry A. Kazakov" wrote in message news:pbs473$co3$1@gioia.aioe.org... > On 26/04/2018 02:04, Randy Brukardt wrote: >> "Dmitry A. Kazakov" wrote in message >> news:pb74sr$1cmf$1@gioia.aioe.org... >>> On 18/04/2018 10:52, Egil H H wrote: >>>> Undefined? >>>> >>>> 9.9(2), "a task is callable unless it is completed or abnormal" >>>> 9.3(5), "A task is said to be completed when the execution of its >>>> corresponding task_body is completed" >>> >>> OK, it is defined enough to confirm that T'Callable cannot be used to >>> break finalization deadlock. >> >> Of course it can: you test T'Callable of your parent task, *not* of >> yourself. If that parent is the environment task, use the >> Task_Identification version. > > No, because the parent task is not going to terminate. "completion" and "termination" are different concepts in Ada, and always have been. A completed task still has to await any tasks nested in it, and do finalization of any objects that it owns. So it still can execute code, make entry calls, and the like. > The problem is to test if the current task is awaited to terminate in > order to have an equivalent of: > > loop > select > terminate; > else > null; > end select; > -- Do a portion of work > end loop; The case I was considering is when the task is directly declared in another task. There is no mechanism to determine whether a task is awaited; I believe that would be a race condition and thus it was omitted from Ada. So if you declare a task in a block there is no practical way to terminate it -- ergo, don't do that. :-) > There is no solution to this below the library level where the environment > task hack works. It works fine if the task's master is another task, and it never works otherwise. It doesn't have anything specifically to do with the environment task -- you can do the same trick with any parent task. > Under the library level an access to the task must be used *and* this > pointer type must be declared one level up the future master of the task. > I.e. it cannot be local in the scope where the object creating the task > lives. This will deadlock as mandated by the RM. There's no problem if the task's master is that of the parent task, as I noted. One way to do that indeed is to use an access-to-task (but it doesn't have to be at library level). If you are looking for something more general, it doesn't exist. Randy.