comp.lang.ada
 help / color / mirror / Atom feed
From: Brosgol@MIT-MULTICS.ARPA
Subject: Re: Propagation of exceptions raised wit
Date: Mon, 9-Jun-86 10:06:00 EDT	[thread overview]
Date: Mon Jun  9 10:06:00 1986
Message-ID: <860609140637.124593@MIT-MULTICS.ARPA> (raw)

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

             reply	other threads:[~1986-06-09 14:06 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1986-06-09 14:06 Brosgol [this message]
  -- strict thread matches above, loose matches on Subject: below --
1986-06-02 16:16 Propagation of exceptions raised within tasks frigo
1986-06-04 14:13 ` Propagation of exceptions raised wit emery
1986-06-06 13:41   ` Doug Bryan
1986-06-06 20:57 ` emery
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox