Re: timer_server triggers Task_Termination handler

["Randy Brukardt" <randy@rrsoftware.com>]

"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.