Propagation of exceptions raised within tasks

Propagation of exceptions raised within tasks

[frigo]

Re: Propagation of exceptions from tasks

Can anyone help me with this problem? It must e[Dbe a programming
error, but I can't find it...

The main procedure instantiates a package TASK_PAK, generic on
the number of tasks to be created. TASK_PAK declares an array
of records containing each a task component. The task body is
S[Dseparate(TASK_PAK).    

Each task has an exception handler of the form

    when OTHERS =>
       raise TASK_CH[DRASHED;

After starting all the tasks (they have an entry START) the main
procdu[D[Dedure goes in a loop in which it performs a selective entry
call to another task[D[D[D[D[D[D[D[D[D[D[D[D[D[CANOTHER task. The main procedure loop looks like this:

  begin
    loop
      select
        KEYBOARD.WAIT_FOR_SHUTDW[DOWN;
        ...
        exit;
      else
        delay 1 * SECS;
    end loop;
   [Dexception
    when TASK_CRASHED =>
      ...
  end;

Usin[D[D[D[DUsing the VAX/Ada de[D[D[D[D[D[D[D[D[D[Ddebugger under VAX/VMS, I can see the exception raisd[Ded
in one of the task being intercepted by the task excepion handler
and raised again as TASK_CRASHED.    However, the main program
stays de[D[DDELAYed on the selective entry call, and its exception
handler is not executed.    Why???

-- 
                       G. Vittorio FRIGO,
                       C.E.R.N., CH - 1211 Geneva 23, Switzerland

Re: Propagation of exceptions raised wit

[emery]

I think you are asking "Why don't exceptions propogate out of tasks?"
If so, don't feel bad, I asserted that they do once in public, and 
was quickly corrected.  

Exceptions do not propogate out of tasks.  If a task raises an exception
that it doesn't handle, the task becomes 'completed', but no further
action (including propogating the exception) takes place.

Quotes from the Canon:  Ada RM, section 11.4.1

"If an exception is raised in the sequence of statements of a frame that
does not have a handler for the exception, execution of the sequence
of statements is abandoned.  The next action depends on the nature of the
frame:

(a)  For a subprogram body, the same exception is raised again at the
point of call of the subprogram, unless the subprogram is the main
program itself, in which case execution of the main program is abandoned.

(b)  For a block statement, the same exception is raised again immediately
after the block statement (that is, within the innermost enclosing frame
or accept statement).

(c)  For a package body that is a declaritive item, the same exception
is raised again immediately after this declarative item (within the
enclosing declarative part).  If the package body is that of a subunit,
the exception is raised again at the place of the corresponding body
stub.  If the package is a library unit, execution of the main program
is abandoned.

(d)  For a task body, the task becomes completed.

An exception that is raised again (as in the above cases (a), (b), (c)) is
said to be propogated, either by the execution of the subprogram, the 
execution of the block statement, or the elaboration of the package body.
No propogation takes place in the case of a task body.  If the frame is 
a subprogram or a block statement and if it has dependent tasks, the 
propogation of an exception takes place only after termination of the
dependent tasks.  

Finally, if an exception is raised in the sequence of statements of an
exception handler, execution of this sequence of statements is abandoned.
Subsequent actions (including propogation, if any) are as in the cases
(a) to (d), above."


So, here's an interesting design problem:  How does a task report
failure due to an exception to its parent?

			Dave Emery
			Siemens Research
UUCP:	   ...princeton!siemens!emery
ARPA:	      princeton!siemens!emery@topaz.rutgers.edu

Re: Propagation of exceptions raised wit

[Doug Bryan]

Dave,

also, don't forget that if an execption is raised during a rendezvous, it
is raised in the task being called and propagated to the calling task
as well.

doug
-------

Re: Propagation of exceptions raised wit

[emery]

Both Frank Prindle and Doug Bryan have reminded me that, should an
exception be raised during rendeveous, the exception is propogated to
BOTH tasks.  This is perfectly consistent with the notion that the
rendeveous code is run 'by both tasks'.  

However, exception propogation, once inside the two tasks, follows
the rule I cited, i.e. the exception is not propogated out of either
task.

Thanks, guys.  

On a related topic:  A command interpreter is one good example of 
a program that may be called to invoke other programs, which are
not known at compile time (see Tom Wheeler's article, cited in 
previous discussions.)  If you presume that all such 'programs' are
tasks, here's my design problem again:  How does a task report
failure to its parent.  One of the problems here is the task name
problem.  A task does not know its identity, therefore it cannot say
things like "I am task 36, and I aborted because of a fubar exception."
The standard way around this is to "christen" the task through an 
entry call, where the caller tells the task its name ("You are task 36").
It seems that a task identity scheme is a necessary condition for having
tasks report their failure.

				Dave Emery
				Princeton Research
UUCP:		   ...princeton!siemens!emery	
ARPA:		      princeton!siemens!emery@topaz.rutgers.edu
					  or @seismo.css.gov

Re: Propagation of exceptions raised wi

[stt]

Quoting from the Ada RM, 11.4.1:4,8 ...
"If an exception is raised in the sequence of statements of a frame
that does not have a handler for the exception [ e.g.
your "raise TASK_CRASHED" ], execution of this sequence
of statements is abandoned.  The next action depends on
the nature of the frame:

. . .
  (d)  For a task body, the task becomes completed."

In other words, exceptions are not propagated out of task bodies.
Even the "master" is unaware that a task completed due to
an unhandled exception.  It only knows that the task completed somehow.

Just to confuse things, exceptions ARE propagated out
of accept bodies, to both the caller and the called task.

Re: Propagation of exceptions raised wit

[Brosgol]

With respect to some recent interchanges on exception propagation and
tasks...

Long ago and far away there was a mechanism in Ada known as the 'FAILURE
exception.  It was an attribute of a task, and the idea was that by
raising FOO'FAILURE you could let task FOO carry out its "last wishes"
before its demise.  Kind of a graceful abort.  Well, it was nice in
theory but proved to be devilish in practice -- it turned out to be
impossible to program task FOO so that it could respond to an exception
that was raised asynchronously.  So 'FAILURE is now an archeological
curiosity rather than a language feature.

The problems with asynchronous exceptions are why exceptions do not propagate
out of tasks.  That is, there is no way of knowing where the parent task
is when the child task raises the exception.  Asynchronous exception raising
would be an unreliable and hard to implement means of synchronization.  So,
sorry about the lack of symmetry between tasks and other units with
respect to exception propagation, but tasks are different in an essential way
here.

If a task must communicate its failure to complete normally, then it should
do so via the recommended synchronization technique -- rendezvous. (If you
like to live dangerously and erroneously I guess you could also
use shared variables.)  If it is important for a parent task to know that
its children have completed successfully, then the parent should rendezvous
with each child when it (the parent) has finished its own business.  Make
sure that each child has a "when others ==> accept DONE(...)" where DONE
has an out parameter that reflects the child's status.  Each child must also
accept DONE when it completes normally.

The program invocation example mentioned by Dave Emery looks like a red
herring as far as the exception propagation issue is concerned.
Program invocation does not follow Ada tasking semantics (the invoked
program and the invoker have no common address space, and the invokee is
not a child task of the invoker -- the invoker does not sit suspended waiting
for the invokee to complete).  So I don't see that it is relevant to the issue
of whether exceptions should or shouldn't propagate.

-Ben Brosgol