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!aioe.org!.POSTED!not-for-mail
From: "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
Newsgroups: comp.lang.ada
Subject: Re: timer_server triggers Task_Termination handler
Date: Fri, 22 Apr 2016 09:25:49 +0200
Organization: Aioe.org NNTP Server
Message-ID: <nfcjmm$1nei$1@gioia.aioe.org>
References: <nfa9nm$bkc$1@loke.gir.dk> <wcca8kmac15.fsf@TheWorld.com>
 <nfcgj3$rea$1@dont-email.me>
NNTP-Posting-Host: G7MXAklp0OAVRSdfcmpxRQ.user.gioia.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Complaints-To: abuse@aioe.org
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.7.2
X-Notice: Filtered by postfilter v. 0.8.2
Xref: news.eternal-september.org comp.lang.ada:30237
Date: 2016-04-22T09:25:49+02:00
List-Id: <comp.lang.ada>

On 22/04/2016 08:36, Georg Bauhaus wrote:
> 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.

I think it should be the task's master to which all task events are 
reported. The master can propagate them further.

Then it must have a form of a rendezvous rather than a callback.

Regarding your example. Tracing hardware utilization is meaningless in 
the form you stated. E.g. how would you trace interrupt handlers, 
drivers etc. You breach virtual machine abstraction, that is not going 
to work. What you can trace is the activity controlled by a master task 
that schedules other tasks. That fits into the model I proposed.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de