timer_server triggers Task_Termination handler

timer_server triggers Task_Termination handler

[Per Dalgas Jakobsen]

Is it correct behaviour when tasks internal to the GNAT run-time causes 
users task_termination handlers to be called?

This behaviour is seen on:
   1) Debian Linux: gnat-5 (Ada 2005, Ada 2012).
   2) AIX: GNAT Pro 6.1.0w (Ada 2005).

A simple demonstration of the issue:

--------------------------------------------------------------------------------
with Ada.Text_IO;
with Log_Unhandled_Exceptions;

procedure Timer_Server_Noise is

begin
    Ada.Text_IO.Put_Line ("Start of main");

    select
       delay 0.5;
    then abort
       loop
          delay 0.1;
       end loop;
    end select;

    Ada.Text_IO.Put_Line ("End of main");
end  Timer_Server_Noise;
--------------------------------------------------------------------------------
with Ada.Exceptions;
with Ada.Task_Identification;
with Ada.Task_Termination;

package Log_Unhandled_Exceptions is

    pragma Elaborate_Body;

    use Ada.Task_Identification;
    use Ada.Task_Termination;
    use Ada.Exceptions;

    --
    protected Last_Wishes is
       procedure Log_Any_Exit (Cause : in Cause_Of_Termination;
                               T     : in Task_Id;
                               E     : in Exception_Occurrence);
    end;

end Log_Unhandled_Exceptions;
--------------------------------------------------------------------------------
with Ada.Text_IO;


package body Log_Unhandled_Exceptions is

    -- Encapsulates the actual log call
    procedure Log (Text : in String) is
    begin
       Ada.Text_IO.Put_Line ("Log_Unhandled_Exceptions >> " &
                               Text);
    end Log;

    --
    protected body Last_Wishes is

       procedure Log_Any_Exit (Cause : in Cause_Of_Termination;
                               T     : in Task_Id;
                               E     : in Exception_Occurrence) is
       begin
          case Cause is
             when Normal =>
                Log ("Normal exit of task: " & Image (T));
             when Abnormal =>
                Log ("Abnormal exit of task: " & Image (T));
             when Unhandled_Exception =>
                Log ("Unhandled exception in task: " & Image (T));
          end case;
       end Log_Any_Exit;

    end Last_Wishes;


begin
    if Current_Task_Fallback_Handler = null then
       Set_Dependents_Fallback_Handler (Last_Wishes.Log_Any_Exit'Access);
    else
       Log ("Fallback handler already set, will not set own handler.");
    end if;

    if Specific_Handler (Current_Task) = null then
       Set_Specific_Handler (Current_Task, Last_Wishes.Log_Any_Exit'Access);

    else
       Log ("Specific handler already set, will not set own handler.");
    end if;
end Log_Unhandled_Exceptions;
--------------------------------------------------------------------------------

~Per

Re: timer_server triggers Task_Termination handler

[Anh Vo]

On Thursday, April 21, 2016 at 3:23:51 AM UTC-7, Per Dalgas Jakobsen wrote:
> Is it correct behaviour when tasks internal to the GNAT run-time causes 
> users task_termination handlers to be called?
> 
> This behaviour is seen on:
>    1) Debian Linux: gnat-5 (Ada 2005, Ada 2012).
>    2) AIX: GNAT Pro 6.1.0w (Ada 2005).
 
Yes, this is correct behavior. See C.7.3 of the Ada Reference Manual,  http://www.adaic.org/resources/add_content/standards/12rm/html/RM-C-7-3.html#I7669

Anh Vo

Re: timer_server triggers Task_Termination handler

[Jacob Sparre Andersen]

Anh Vo wrote:

> On Thursday, April 21, 2016 at 3:23:51 AM UTC-7, Per Dalgas Jakobsen wrote:
>> Is it correct behaviour when tasks internal to the GNAT run-time causes 
>> users task_termination handlers to be called?
>  
> Yes, this is correct behavior. See C.7.3 of the Ada Reference Manual,

I can't see anywhere in section C.7.3, which allows the compiler to
insert "spontaneous" calls to the termination handlers.

Greetings,

Jacob
-- 
"We will be restoring normality as soon as we are sure what is normal anyway."

Re: timer_server triggers Task_Termination handler

[Anh Vo]

On Thursday, April 21, 2016 at 11:20:34 AM UTC-7, Jacob Sparre Andersen wrote:
> Anh Vo wrote:
> 
> > On Thursday, April 21, 2016 at 3:23:51 AM UTC-7, Per Dalgas Jakobsen wrote:
> >> Is it correct behaviour when tasks internal to the GNAT run-time causes 
> >> users task_termination handlers to be called?
> >  
> > Yes, this is correct behavior. See C.7.3 of the Ada Reference Manual,
> 
> I can't see anywhere in section C.7.3, which allows the compiler to
> insert "spontaneous" calls to the termination handlers.

How about paragraph 13/3 of C.7.3.

Anh Vo

Re: timer_server triggers Task_Termination handler

[Randy Brukardt]

"Per Dalgas Jakobsen" <pdj@knaldgas.dk> 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.

Re: timer_server triggers Task_Termination handler

[Robert A Duff]

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.

I fixed this bug in GNAT recently.

- Bob

Re: timer_server triggers Task_Termination handler

[J-P. Rosen]

Le 21/04/2016 23:13, Randy Brukardt a écrit :
> 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.

It could be considered user-friendly for hidden tasks in reusable
components to specify a task specific handler, so that they remain
hidden if the user specifies a general handler.

But I agree that it would be difficult to /require/ this in the ARM.

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: timer_server triggers Task_Termination handler

[Georg Bauhaus]

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.

Re: timer_server triggers Task_Termination handler

[Jacob Sparre Andersen]

Randy Brukardt wrote:

> "Per Dalgas Jakobsen" <pdj@knaldgas.dk> 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?

Maybe because you end up having to inspect the run-time library to
figure out why your application behaves like it does?

Or because it makes the behaviour of your program depend on which (correct)
run-time library you compile it with?

> And what about tasks in third-party libraries?

In my opinion third-party libraries are a different matter from the
run-time provided by the compiler.

I would definitely expect the handlers to be called for any tasks
declared outside the run-time.

Greetings,

Jacob

PS: I agree that the compiler providers should write as much as possible
    of the run-time library in Ada.
-- 
... but, following long-established custom, it is Laplace's result
that is always called, in the modern litterature, "Bayes' theorem." (Jaynes)

Re: timer_server triggers Task_Termination handler

[Dmitry A. Kazakov]

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

Re: timer_server triggers Task_Termination handler

[G.B.]

On 22.04.16 09:25, Dmitry A. Kazakov wrote:
> Tracing hardware utilization is meaningless in the form you stated.

Specifically, allocate tasks to processors, also know
about which tasks are allocated to which processors,
in order to stay in control of what happens where,
and what has failed to happen there, in case it has.

Of course, that's denying the abstraction that an OS
might want to provide, but I think this is a reasonable
view in cases where Ada programs operate a system in
a predictable way.

Re: timer_server triggers Task_Termination handler

[Dmitry A. Kazakov]

On 22/04/2016 12:05, G.B. wrote:
> On 22.04.16 09:25, Dmitry A. Kazakov wrote:
>> Tracing hardware utilization is meaningless in the form you stated.
>
> Specifically, allocate tasks to processors, also know
> about which tasks are allocated to which processors,
> in order to stay in control of what happens where,
> and what has failed to happen there, in case it has.

The point is that it must be your scheduler to make sense. You scheduler 
will be able to know that.

> Of course, that's denying the abstraction that an OS
> might want to provide, but I think this is a reasonable
> view in cases where Ada programs operate a system in
> a predictable way.

Then it is the case of a custom scheduler task.

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

Re: timer_server triggers Task_Termination handler

[G.B.]

On 22.04.16 14:55, Dmitry A. Kazakov wrote:
> The point is that it must be your scheduler to make sense. You scheduler
> will be able to know that.

What does "your" stand for and what ownership relation exists
between the program, the scheduler (whose), and run-time tasks'
termination events?

Re: timer_server triggers Task_Termination handler

[Dmitry A. Kazakov]

On 22/04/2016 15:33, G.B. wrote:
> On 22.04.16 14:55, Dmitry A. Kazakov wrote:
>> The point is that it must be your scheduler to make sense. You scheduler
>> will be able to know that.
>
> What does "your" stand for and what ownership relation exists
> between the program, the scheduler (whose), and run-time tasks'
> termination events?

The schedule is the master of these tasks. The point is that events must 
be reported to the task's master. That eliminates the problem of 
ambiguity which tasks, threads, services, drivers, interrupts, embedded 
procedures, co-routines etc must generate events.

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

Re: timer_server triggers Task_Termination handler

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:nfcjmm$1nei$1@gioia.aioe.org...
...
> I think it should be the task's master to which all task events are 
> reported. The master can propagate them further.

That's how general termination handlers work. In this case, the "master" is 
the environment task, which is the master of all tasks in the Ada program 
(recall that masters are nested, most tasks belong a number of masters). The 
question here is whether the Ada implementer should be deciding that some 
tasks should be excluded from such reporting.

                                Randy.

Re: timer_server triggers Task_Termination handler

[Randy Brukardt]

"Robert A Duff" <bobduff@TheWorld.com> wrote in message 
news:wcca8kmac15.fsf@TheWorld.com...
> 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.

Nice thought, but exactly the opposite to some of opinions in the e-mail 
associated with the design of the task termination feature. They wanted to 
be notified if an internal task failed (presumably to narrow down the cause 
of the inevitable failure cascade that follows).

Given the Ada definition, it is wrong to hide an Ada task. Of course, there 
is no reason to use Ada tasks in the runtime (the runtime could be written C 
or Prolog ;-), so there is no truely wrong answer here.

                             Randy.

Re: timer_server triggers Task_Termination handler

[Dmitry A. Kazakov]

On 2016-04-23 00:31, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:nfcjmm$1nei$1@gioia.aioe.org...
> ....
>> I think it should be the task's master to which all task events are
>> reported. The master can propagate them further.
>
> That's how general termination handlers work. In this case, the "master" is
> the environment task, which is the master of all tasks in the Ada program
> (recall that masters are nested, most tasks belong a number of masters). The
> question here is whether the Ada implementer should be deciding that some
> tasks should be excluded from such reporting.

But the environment task is not an explicitly declared Ada task. It is 
implementation-dependent, so the ambiguity. If it is a "real" task 
starting "real" implementation tasks, they must be reported. If the 
implementation tasks are not Ada tasks started by non-Ada means, they 
cannot be reported or too difficult to.

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

Re: timer_server triggers Task_Termination handler

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:nffgqa$6b6$1@gioia.aioe.org...
> On 2016-04-23 00:31, Randy Brukardt wrote:
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>> news:nfcjmm$1nei$1@gioia.aioe.org...
>> ....
>>> I think it should be the task's master to which all task events are
>>> reported. The master can propagate them further.
>>
>> That's how general termination handlers work. In this case, the "master" 
>> is
>> the environment task, which is the master of all tasks in the Ada program
>> (recall that masters are nested, most tasks belong a number of masters). 
>> The
>> question here is whether the Ada implementer should be deciding that some
>> tasks should be excluded from such reporting.
>
> But the environment task is not an explicitly declared Ada task. It is 
> implementation-dependent, so the ambiguity.

There's nothing "implementation-dependent" about the environment task; it 
has to exist in any correct Ada implementation.

> If it is a "real" task starting "real" implementation tasks, they must be 
> reported.

The environment task has to be a "real" task (or at least, appear to be in 
the effects of the runtime library).

> If the implementation tasks are not Ada tasks started by non-Ada means, 
> they cannot be reported or too difficult to.

But this is correct: if the implementation tasks aren't Ada tasks, then of 
course they don't get reported. The language has nothing to say about 
whether the runtime is implemented in Ada or not. (For users that are doing 
detailed analysis of task behavior, hidden not-quite-tasks might be a 
problem, but it probably doesn't matter for the majority of users.)

                                 Randy.