* select delay; then abort... in Annex E @ 2006-09-30 22:31 Dr. Adrian Wrigley 2006-10-02 7:33 ` Alex R. Mosteo 0 siblings, 1 reply; 7+ messages in thread From: Dr. Adrian Wrigley @ 2006-09-30 22:31 UTC (permalink / raw) 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. 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? Thanks in advance. -- Adrian ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: select delay; then abort... in Annex E 2006-09-30 22:31 select delay; then abort... in Annex E Dr. Adrian Wrigley @ 2006-10-02 7:33 ` Alex R. Mosteo 2006-10-03 11:20 ` Dr. Adrian Wrigley 0 siblings, 1 reply; 7+ messages in thread From: Alex R. Mosteo @ 2006-10-02 7:33 UTC (permalink / raw) 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). > 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: select delay; then abort... in Annex E 2006-10-02 7:33 ` Alex R. Mosteo @ 2006-10-03 11:20 ` Dr. Adrian Wrigley 2006-10-03 11:33 ` Dr. Adrian Wrigley ` (2 more replies) 0 siblings, 3 replies; 7+ messages in thread From: Dr. Adrian Wrigley @ 2006-10-03 11:20 UTC (permalink / raw) 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. <example below> 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 <all the way up to 100> M= 1 <all the way up to ten> $ 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; $ ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: select delay; then abort... in Annex E 2006-10-03 11:20 ` Dr. Adrian Wrigley @ 2006-10-03 11:33 ` Dr. Adrian Wrigley 2006-10-03 13:01 ` Alex R. Mosteo 2006-10-03 19:16 ` Jeffrey R. Carter 2 siblings, 0 replies; 7+ messages in thread From: Dr. Adrian Wrigley @ 2006-10-03 11:33 UTC (permalink / raw) On Tue, 03 Oct 2006 11:20:23 +0000, Dr. Adrian Wrigley wrote: > 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. <example below> Interestingly, the test case works exactly correctly on GNAT 3.15p. I think this is the behaviour described in the ARM. The RCI call *is* aborted successfully, and the calling task does not carry on. $ cmain J= 1 J= 2 J= 3 J= 4 Abort to be called Abort returned. The program should stop shortly. $ -- Adrian ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: select delay; then abort... in Annex E 2006-10-03 11:20 ` Dr. Adrian Wrigley 2006-10-03 11:33 ` Dr. Adrian Wrigley @ 2006-10-03 13:01 ` Alex R. Mosteo 2006-10-03 19:16 ` Jeffrey R. Carter 2 siblings, 0 replies; 7+ messages in thread From: Alex R. Mosteo @ 2006-10-03 13:01 UTC (permalink / raw) Dr. Adrian Wrigley wrote: > 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. <example below> I'm sorry, I'm leaving for a two weeks trip and don't have glade installed nor the time to thinker right now. I'm using linux too, anyways. > > 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 > <all the way up to 100> > M= 1 > <all the way up to ten> > $ 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; > $ ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: select delay; then abort... in Annex E 2006-10-03 11:20 ` Dr. Adrian Wrigley 2006-10-03 11:33 ` Dr. Adrian Wrigley 2006-10-03 13:01 ` Alex R. Mosteo @ 2006-10-03 19:16 ` Jeffrey R. Carter 2006-10-03 22:31 ` Dr. Adrian Wrigley 2 siblings, 1 reply; 7+ messages in thread From: Jeffrey R. Carter @ 2006-10-03 19:16 UTC (permalink / raw) 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? 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; -- Jeff Carter "You empty-headed animal-food-trough wiper." Monty Python & the Holy Grail 04 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: select delay; then abort... in Annex E 2006-10-03 19:16 ` Jeffrey R. Carter @ 2006-10-03 22:31 ` Dr. Adrian Wrigley 0 siblings, 0 replies; 7+ messages in thread From: Dr. Adrian Wrigley @ 2006-10-03 22:31 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2006-10-03 22:31 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2006-09-30 22:31 select delay; then abort... in Annex E Dr. Adrian Wrigley 2006-10-02 7:33 ` Alex R. Mosteo 2006-10-03 11:20 ` Dr. Adrian Wrigley 2006-10-03 11:33 ` Dr. Adrian Wrigley 2006-10-03 13:01 ` Alex R. Mosteo 2006-10-03 19:16 ` Jeffrey R. Carter 2006-10-03 22:31 ` Dr. Adrian Wrigley
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox