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!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!gandalf.srv.welterde.de!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: timer_server triggers Task_Termination handler Date: Thu, 21 Apr 2016 16:13:45 -0500 Organization: JSA Research & Innovation Message-ID: References: NNTP-Posting-Host: rrsoftware.com X-Trace: loke.gir.dk 1461273226 6127 24.196.82.226 (21 Apr 2016 21:13:46 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Thu, 21 Apr 2016 21:13:46 +0000 (UTC) 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.6157 Xref: news.eternal-september.org comp.lang.ada:30230 Date: 2016-04-21T16:13:45-05:00 List-Id: "Per Dalgas Jakobsen" wrote in message news:nfa9nm$bkc$1@loke.gir.dk... > Is it correct behaviour when tasks internal to the GNAT run-time causes > users task_termination handlers to be called? Sure, why not? In your example, you set a handler for all dependent tasks of the environment task (that is, ALL tasks). C.7.3 doesn't specify who wrote the task or for what purpose. If it is a dependent of the environment task, your handler will be called. We've always encouraged implementers to write some or all of their runtime in Ada. It would increase the difficulty quite a bit if one had to "cover up" the effects of using Ada to write the code. And I can't quite imagine what rule one write to exclude tasks that happen to be in library code. If one said to exclude tasks only if they are in language-defined packages, then you'll still get the tasks that happen to occur in implemention-defined stuff. And since that sort of stuff underlies many language-defined packages, and often is visible to the user as well, how do you account for tasks in such implementation-defined packages. (Surely I hope it doesn't depend on how the package is used!) And what about tasks in third-party libraries? Claw, for instance, includes a hidden task. Should that be excluded? Should it be excluded only in Janus/Ada (where Claw is not a third-party library) but included in GNAT (where Claw is essentially user code)? That way seems to lead to madness. Rereading some of the mail on the original AI, part of the intent was that one could set a handler on ALL tasks, including those not visible to the programmer (hidden in package bodies). If you can see the tasks and only want specific tasks involved, specific handlers make more sense. So in summary I believe this is working the way it was intended. Perhaps we should have put a note in that "all descendent tasks" include tasks that aren't visible to the programmer (hidden in the runtime or third-party packages), but clearly the idea was that the handler would work on every task in the partition, no matter what is its source. Randy.