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=0.7 required=5.0 tests=BAYES_00,MSGID_RANDY autolearn=no 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 11:20:08 PST Path: supernews.google.com!sn-xit-02!supernews.com!news.gv.tsc.tdk.com!news.iac.net!news-out.cwix.com!newsfeed.cwix.com!news.maxwell.syr.edu!nntp2.deja.com!nnrp1.deja.com!not-for-mail From: Ted Dennison Newsgroups: comp.lang.ada Subject: Re: Need advice on Reminder program Date: Wed, 31 Jan 2001 19:08:46 GMT Organization: Deja.com Message-ID: <959nrl$rk5$1@nnrp1.deja.com> References: <9598bo$c95$1@nnrp1.deja.com> NNTP-Posting-Host: 204.48.27.130 X-Article-Creation-Date: Wed Jan 31 19:08:46 2001 GMT X-Http-User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; 0.7) Gecko/20010109 X-Http-Proxy: 1.0 x67.deja.com:80 (Squid/1.1.22) for client 204.48.27.130 X-MyDeja-Info: XMYDJUIDtedennison Xref: supernews.google.com comp.lang.ada:4776 Date: 2001-01-31T19:08:46+00:00 List-Id: In article , 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/