Re: select delay; then abort... in Annex E

["Dr. Adrian Wrigley" <amtw@linuxchip.demon.co.uk.uk.uk>]

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;
$