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

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

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