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-Thread: 103376,bccb34741ee584f4 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news3.google.com!news.glorb.com!news-in.ntli.net!newsrout1-win.ntli.net!ntli.net!news.highwinds-media.com!newspeer1-win.ntli.net!newsfe3-gui.ntli.net.POSTED!53ab2750!not-for-mail From: "Dr. Adrian Wrigley" Subject: Re: select delay; then abort... in Annex E User-Agent: Pan/0.14.2 (This is not a psychotic episode. It's a cleansing moment of clarity.) Message-Id: Newsgroups: comp.lang.ada References: <4obtmjFdug6mU1@individual.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Date: Tue, 03 Oct 2006 22:31:46 GMT NNTP-Posting-Host: 82.10.238.153 X-Trace: newsfe3-gui.ntli.net 1159914706 82.10.238.153 (Tue, 03 Oct 2006 23:31:46 BST) NNTP-Posting-Date: Tue, 03 Oct 2006 23:31:46 BST Organization: NTL Xref: g2news2.google.com comp.lang.ada:6856 Date: 2006-10-03T22:31:46+00:00 List-Id: On Tue, 03 Oct 2006 19:16:53 +0000, Jeffrey R. Carter wrote: > Dr. Adrian Wrigley wrote: >> >> What happens is that the RCI call continues to completion. All >> subsequent delay statements in the task take minimal time(!), >> but the task continues to run. It can successfully call RCI >> units, and proceeds as normal (other than the instant delay statements) >> until it completes. > > Are you trying to abort a procedure that takes longer to execute than > your delay, or a remote call that is not returning when the procedure > has completed execution? Mostly the former. But the latter case suggests some kind of fault. I'm looking to protect the caller from getting held up by a problem somewhere in the call. Perhaps the callee is stuck swapping heavily, has delays in communication or similar. > If the former, can you move the time out to the procedure? > > Remoteprocedure (Timeout_Interval => 10.0, Timed_Out => Timed_Out); > > if Timed_Out then > Complain; > end if; This is a good suggestion. It will handle the example nicely, provided everything is running properly. It's the problem cases I want to catch where, for example, the RCI call doesn't start (no spare tasks). Partly it's a matter of confidence in the integrity of the system. Who's to say the time out in the remote procedure will work? Maybe if it does a remote call itself, that'll fail too. Also, it does mean changing the interfaces, moving the boundaries of responsibility. Perhaps it could raise a Timed_Out exception (remotely). Since I sent the initial message, I have found that the problem is caused by aborts failing in tasks which have made RCI calls. Even a simple abort from another task does not work properly. GNAT 3.15 did this OK. The fix, of course, is to get a working Annex E implementation. But in the mean time, I'll have to work around the limitations. I'll use your suggestion if it becomes necessary. Currently, I kill the whole partition instead, but this isn't good. Thanks. -- Adrian