Re: Need advice on Reminder program

[Ted Dennison <dennison@telepath.com>]

In article <slrn97g027.td.randhol+abuse@kiuk0156.chembio.ntnu.no>,
  randhol+abuse@pvv.org (Preben Randhol) wrote:

> suddenly stop reminding me about appointments I have. I want to make a
> small daemon that reads in a text file with appointments and warn me
> by popping up a dialog on the screen (possibly sound effect and more
> later, but not now I want to keep it simple and reliable).
>
> My thought is to use tasks for this. One task that pop up the dialogs,
> one that read the text file and one that keeps track of the time. I do
> not have experience with tasks so I am wondering if this is a stupid
> approach :-) ? Is there something I should look out for so that the
> daemon won't suddenly stop working. I want a really reliable program
> :-).

Seems sensible to me. The issues I can see off the top of my head that a
tasking newbie needs to be aware of are:

  o  By default, Ada tasks die silently when an unhandled exception is
raised. That can be really rough for debugging. You should probably put
some kind of last-ditch exception handler at the outermost scope of
every task to somehow let you know that the task is dying.

  o  Most I/O calls and GUI operations assume that only one task will
ever make a call on the same object. You should organize things to make
this so.

  o  If you are running on Linux using FSU threads, then I believe any
non-Ada operation (eg: OS I/O calls, some GUI ops) that blocks the task
will block the *entire* program. I'd solve this problem by using the
native threads instead of FSU (unless you need a validated system for
some reason).

  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.

Note that points 1 and 2 together imply that just about any tasking
program needs some kind of message logging task to handle the sending of
error messages to the user.

--
T.E.D.

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


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