From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,2b4035d737f33f74 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-01-31 08:42:02 PST Path: supernews.google.com!sn-xit-02!supernews.com!news.tele.dk!128.39.3.166!uninett.no!ntnu.no!randhol+abuse From: randhol+abuse@pvv.org (Preben Randhol) Newsgroups: comp.lang.ada Subject: Re: Need advice on Reminder program Date: Wed, 31 Jan 2001 16:42:01 +0000 (UTC) Organization: Norwegian university of science and technology Message-ID: References: <9598bo$c95$1@nnrp1.deja.com> NNTP-Posting-Host: kiuk0156.chembio.ntnu.no X-Trace: tyfon.itea.ntnu.no 980959321 14043 129.241.83.82 (31 Jan 2001 16:42:01 GMT) X-Complaints-To: usenet@itea.ntnu.no NNTP-Posting-Date: Wed, 31 Jan 2001 16:42:01 +0000 (UTC) User-Agent: slrn/0.9.6.3 (Linux) Xref: supernews.google.com comp.lang.ada:4769 Date: 2001-01-31T16:42:01+00:00 List-Id: On Wed, 31 Jan 2001 14:44:11 GMT, Ted Dennison wrote: >In article , > > > 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. Yes I'll do that :-) 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 possible to have a task that is "overlooking" the others and restart one that has died? > 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. Yes I thought I'd use three different tasks. The task doing I/O puts the appointments in a list and gives this to the task that keeps track of the time. This task will then pass a text string to the GUI task with the info to be displayed. > 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). Hmm OK. I don't know what I have, I'll check that. > 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. >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. Noted. Thanks for the help. -- Preben Randhol ---------------- http://www.pvv.org/~randhol/ -- iMy favorite editor is Emacs!bcwVim -- vim best-editor.txt