is_callable(environment)?

is_callable(environment)?

[Tom Moran]

An app has a library level task that would like to use a select with a
terminate alternative, but can't since the task must periodically poll
hardware via a delay alternative.  Using
ada.task_identification.is_callable as in
  main_program : task_id;
begin
  accept start_up do
     main_program := start_up'caller;
  end start_up;
...
  loop
     exit when not is_callable(main_program);
     select ...
appears to work on the three compilers I've tried so far, but I wonder
if I'm just very lucky, or if most compilers take the allowance of
C.7.1(21) and allow 'caller to return a task_id of the environment
task, and if is_callable on the environment task becomes false when it
reaches the end of the main program and before its dependent tasks
have terminated and library level controlled objects have finalized.

Re: is_callable(environment)?

[Robert Dewar]

<<appears to work on the three compilers I've tried so far, but I wonder
if I'm just very lucky, or if most compilers take the allowance of
C.7.1(21) and allow 'caller to return a task_id of the environment
task, and if is_callable on the environment task becomes false when it
reaches the end of the main program and before its dependent tasks
have terminated and library level controlled objects have finalized.
>>>

You are lucky, there is no reason to think this would always work!

Re: is_callable(environment)?

[Tom Moran]

>there is no reason to think this would always work!
Of course.  That's why I asked " if most compilers " have this useful
capability..  Gnat is one of the three I've tested so far and it
currently does.  I presume, of course, that  ACT reserves the right to
remove it without notice, since it is  not a *required*. capability.

Re: is_callable(environment)?

[Tucker Taft]

Tom Moran (tmoran@bix.com) wrote:

: ... but I wonder
: if I'm just very lucky, or if most compilers take the allowance of
: C.7.1(21) and allow 'caller to return a task_id of the environment
: task, and if is_callable on the environment task becomes false when it
: reaches the end of the main program and before its dependent tasks
: have terminated and library level controlled objects have finalized.

The environment task is a task, so 'Caller, 
Ada.Task_Identification.Current_Task, etc., all need to work on it.

There is also nothing that disallows Is_Callable(env-task-id), so
calling it should be "safe."  However, it is pretty easy to
imagine that the mechanism for waiting for library-level tasks
follows a different path in the run-time system than that used
when exiting an "explicit" task body, so it seems possible that
Is_Callable(env-task) might remain true indefinitely (or perhaps false
indefinitely).  Clearly, you will need to test this out on
each Ada run-time you intend to use.

--
-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Burlington, MA  USA

Re: is_callable(environment)?

[Jean-Pierre Rosen]

I am puzzled by Robert's response here.

Every task has a task ID, and I don't think there is something in the
reference manual that says that the environment task is treated differently.

C.7.1(21) is a *note*, not an *implementation permission*. My understanding
is that it points out that if the current task is the environment task, then
calling Current_Task will return its task-ID, and therefore that it can be
used safely even with the environment task.

Therefore, I would say that the proposed program should always work.
--
----------------------------------------------------------------------------
                  J-P. Rosen (Rosen.Adalog@wanadoo.fr)
      Visit Adalog's web site at http://perso.wanadoo.fr/adalog

Robert Dewar a �crit dans le message ...
><<appears to work on the three compilers I've tried so far, but I wonder
>if I'm just very lucky, or if most compilers take the allowance of
>C.7.1(21) and allow 'caller to return a task_id of the environment
>task, and if is_callable on the environment task becomes false when it
>reaches the end of the main program and before its dependent tasks
>have terminated and library level controlled objects have finalized.
>>>>
>
>You are lucky, there is no reason to think this would always work!
>