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!newsfe4-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 11:20:23 GMT NNTP-Posting-Host: 82.10.238.153 X-Trace: newsfe4-gui.ntli.net 1159874423 82.10.238.153 (Tue, 03 Oct 2006 12:20:23 BST) NNTP-Posting-Date: Tue, 03 Oct 2006 12:20:23 BST Organization: NTL Xref: g2news2.google.com comp.lang.ada:6846 Date: 2006-10-03T11:20:23+00:00 List-Id: On Mon, 02 Oct 2006 09:33:46 +0200, Alex R. Mosteo wrote: > Dr. Adrian Wrigley wrote: > >> Hi guys, >> >> Things are now working *much* better with my Annex E setup here. >> >> The server hasn't been totally free of problems, but at least I >> can't point the finger at Glade this time ;-) >> >> I wanted to limit the execution time of a partition. So I tried >> something like: >> >> select >> delay 10.0; >> Complain; >> then abort >> RemoteProcedure; >> end select; >> >> the intent was that the partition would terminate if the >> RemoteProcedure exceeded the alloted 10s of execution time. >> >> Unfortunately, what happens is that the code runs for the full >> duration of the RemoteProcedure (say 10 minutes), then it >> invokes Complain, finally exiting. > > This is the behavior you get if you try the same with a Text_Io.Get_Line > call (that indeed is potentially blocking IO). The strange thing is that the statement sequence in the abortable part executes right to the end (if there are several). I would have thought the abort would happen as soon as it completes a blocking operation. Regardless, it's a real nuisance if any remote call can hold up a task indefinitely. I need real-time operation of my program (although at a *much* lower speed/latency than most software called "real-time"). >> Why can't the RemoteProcedure be aborted? Is it because it >> is a blocking operation (E.4.17)? E.4.13 suggests the construct >> can be aborted (cancelling the remote operation), but the >> above code suggests it can't. >> >> Is there a way to get my partition to terminate regardless >> of outstanding remote calls? > > An idea is to do it the dirty way, creating a new task to do the call and > aborting it the rough way. I've taken a quick look at ARM05/9.8.5 but > couldn't conclude anything. I had already tried this. I used abort on a named task. It didn't seem to do what I expected. 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. I have put together a test case which illustrates this. Once a task has executed a RCI call, it cannot be aborted properly at all :( (GNAT GPL 2006, Linux, FC5 i686) Can anyone out there try this example for me please? (correct behaviour is to count to about six, then the program terminates. Thanks. -- Adrian $ ls *.ad[sb] *cfg a.adb a.ads cmain.adb dist.cfg $ gnatdist -q dist.cfg $ cmain # Illustrates incorrect behaviour J= 1 J= 2 J= 3 J= 4 Abort to be called Abort returned. The program should stop shortly. J= 5 J= 6 M= 1 $ cat *.ad[sb] *cfg package body A is function Next return Integer is begin return 0; end Next; end A; package A is pragma Remote_Call_Interface; pragma All_Calls_Remote; function Next return Integer; end A; with Text_IO; with A; procedure CMain is task AbortTest; task body AbortTest is X : Integer; begin for J in 1 .. 100 loop X := A.Next; -- Delete this line for correct behaviour delay 1.0; Text_IO.Put_Line ("J=" & Integer'Image (J)); end loop; for M in 1 .. 10 loop for K in 1 .. 600_000_000 loop null; end loop; Text_IO.Put_Line ("M=" & Integer'Image (M)); end loop; end AbortTest; begin delay 5.0; Text_IO.Put_Line ("Abort to be called"); abort AbortTest; Text_IO.Put_Line ("Abort returned. The program should stop shortly."); end CMain; configuration Dist is APart : Partition := (A, CMain); procedure CMain is in APart; end Dist; $