Re: Need advice on Reminder program

[Ted Dennison <dennison@telepath.com>]

In article <slrn97gg4p.113.randhol+abuse@kiuk0156.chembio.ntnu.no>,
  randhol+abuse@pvv.org (Preben Randhol) wrote:
> On Wed, 31 Jan 2001 14:44:11 GMT, Ted Dennison wrote:
> >  o  By default, Ada tasks die silently when an unhandled exception
> >is raised. That can be really rough for debugging. You should
> Does this mean that all the tasks will die or does it mean that only
> the one task where the exception occurs dies? If the latter is it

Only the one task where the exception occurs. However, if an exception
occurs within the "do ... end" part of a rendezvous accect, then it gets
propagated out to *both* taks.

> possible to have a task that is "overlooking" the others and restart
> one that has died?

I have taken that approach in the past with mission-critical software.
You'd have to make the task a task *type*, so that a new task object can
be created. The only problem is that it is also concievable for the
"manager" task itself to die. To prevent that, I added another managed
task called the "ombudsman" to watch and restart the "manager". They
could still *both* die at the same time, but we weren't required to
handle multiple failures. :-)

Another possibliity would be to put the entire task's functionality in a
(infinite) loop, and put the exception-handling block immediately inside
the loop. As long as you can trust the loop not to raise an exception,
that'll keep the task running. But you have to have some usable recovery
mechanism.

In most cases I'd say the best approach is to have it just spit out an
error to a log, then let it die. Then you can just fix the bug so it
doesn't happen again.


> >  o  A task should generally be designated as either a client
> >(initiates rendezvous) or a server (accepts rendezvous). The
> >situations where you can get away with doing both in the same task
> >without danger of deadlock or undesired extended blocking are rare.
>
> I see. Perhaps I should use a protected object.

Protected objects are damn useful for reducing the number of tasks in a
system. Unfortunately, can only be treated as servers (under the scheme
I outlined above), so they are only useful for interfacing clients to
clients. Think of them as sort of a software gender-bender. :-)

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com
http://www.deja.com/