select delay; then abort... in Annex E

select delay; then abort... in Annex E

[Dr. Adrian Wrigley]

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

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

[Alex R. Mosteo]

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.

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

[Dr. Adrian Wrigley]

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

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

[Dr. Adrian Wrigley]

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

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

[Alex R. Mosteo]

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

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

[Jeffrey R. Carter]

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

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

[Dr. Adrian Wrigley]

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