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=-0.3 required=5.0 tests=BAYES_00,
	REPLYTO_WITHOUT_TO_CC autolearn=no 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!.POSTED!not-for-mail
From: Georg Bauhaus <bauhaus@futureapps.invalid>
Newsgroups: comp.lang.ada
Subject: Re: timer_server triggers Task_Termination handler
Date: Fri, 22 Apr 2016 08:36:31 +0200
Organization: A noiseless patient Spider
Message-ID: <nfcgj3$rea$1@dont-email.me>
References: <nfa9nm$bkc$1@loke.gir.dk> <wcca8kmac15.fsf@TheWorld.com>
Reply-To: nonlegitur@futureapps.de
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Fri, 22 Apr 2016 06:33:07 -0000 (UTC)
Injection-Info: mx02.eternal-september.org;
 posting-host="970e99b66d1035a2e932906bf445a96c";
	logging-data="28106"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX19svbb6Sy2SGIMRctbWO+v+uDgb8VfiZIg="
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0)
 Gecko/20100101 Thunderbird/38.7.2
In-Reply-To: <wcca8kmac15.fsf@TheWorld.com>
Cancel-Lock: sha1:mQXJScx8C5wmmx6RaEtlOTV7Ltc=
Xref: news.eternal-september.org comp.lang.ada:30235
Date: 2016-04-22T08:36:31+02:00
List-Id: <comp.lang.ada>

On 21.04.16 23:26, Robert A Duff wrote:
> Per Dalgas Jakobsen <pdj@knaldgas.dk> writes:
>
>> Is it correct behaviour when tasks internal to the GNAT run-time causes
>> users task_termination handlers to be called?
>
> No.  Internal tasks are an implementation detail, and should be
> invisible to Ada programs.

Should whatever the Ada program includes from the run-time
have hidden effects only? Inaccessible in a black box, with
thick walls, and no outlets?

> I fixed this bug in GNAT recently.
>

 From Randy's response, I understand that "bug" might be only one
reading. Suppose that program development needs to trace hardware
utilization, or generally the life of _all_ task objects. Should this
not be available using some standard mechanism?

ALL(x)[x is task_termination -> x is event]

     changed to mean

ALL(x)[x is task_termination ->
          x'task visible in the program -> x is event]

revokes access to all source-invisible run-time effects, or events.
A registration scheme more flexible than ALL vs ALL that you know about,
or ALL that we choose for you, seems another reading more open to
project needs.