comp.lang.ada
 help / color / mirror / Atom feed
From: "Dr. Adrian Wrigley" <amtw@linuxchip.demon.co.uk.uk.uk>
Subject: Re: Distributed Ada, robustness etc.
Date: Thu, 25 May 2006 01:12:08 GMT
Date: 2006-05-25T01:12:08+00:00	[thread overview]
Message-ID: <pan.2006.05.25.01.10.38.796525@linuxchip.demon.co.uk.uk.uk> (raw)
In-Reply-To: pan.2006.05.23.12.12.56.531577@linuxchip.demon.co.uk.uk.uk

On Tue, 23 May 2006 12:14:05 +0000, Dr. Adrian Wrigley wrote:

> Up until now, I have been using fairly elementary Annex E features
> with GNAT/GLADE on Linux.
<snip>

Hmm.  Seems to have gone quiet round here!

OK. I've prototyped a system based on LRM E.4.2 (p. 412), where a
Remote_Call_Interface unit registers servers as they are instantiated.

This will work nicely, except for the single point of failure
issue resulting from having RCI units, and the following nuisance:

EITHER
every subprogram declaration using the remote despatching type
has to refer to it as "access Tape" (or whatever the type is called),

procedure Rewind (T : access Tape) is abstract; -- need to add "access"
...
TapeAccess := Find ("NINE-TRACK");
...
Rewind (TapeAccess);

Or

every despatching call needs to dereference an access variable
(so calls become something like "Tapes.Rewind (TapeAccess.all);")

procedure Rewind (T : Tape) is abstract;
...
TapeAccess := Find ("NINE-TRACK");
...
Rewind (TapeAccess.all); -- Need to add ".all" for every call!

I'd rather not change all my code to say "access" or "all" every
time I define or use one of these calls (lazy).  The only solution
I have come up with to avoid modifying the existing code to have
"all" with every call is to define a corresponding set of subprograms
which take the access values as parameters, and call the underlying
(remote) despatching interface by dereferencing it in the body.

So the code would become:

procedure Rewind (T : Tape) is abstract; -- unchanged code
procedure Rewind (T : access Tape) is begin Rewind (T.all); end Rewind;
...
TapeAccess := Find ("NINE-TRACK");
...
Rewind (TapeAccess); -- unchanged code

Am I missing a better, more obvious solution?

(interestingly, the remote despatching call may fail from
communications errors or other failure.  The corresponding
non-remote call can handle the exception by using the "Find"
to get another server to call instead, or take other
recovery actions.  Perhaps this is the way to go...)

I'm still thinking about eliminating the RCI failure point.

I'm wondering whether Annex E has ever been used as a basis
for a big commercial project...
--
Adrian





  reply	other threads:[~2006-05-25  1:12 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-23 12:14 Distributed Ada, robustness etc Dr. Adrian Wrigley
2006-05-25  1:12 ` Dr. Adrian Wrigley [this message]
2006-05-25 10:34   ` Dmitry A. Kazakov
2006-05-29  0:55   ` Dr. Adrian Wrigley
2006-05-30 15:11     ` Dr. Adrian Wrigley
2006-05-31  5:49       ` Ludovic Brenta
2006-05-31 12:40         ` Dr. Adrian Wrigley
2006-05-31 13:21           ` Jean-Pierre Rosen
2006-05-31 14:38             ` Dr. Adrian Wrigley
2006-05-31 15:38               ` Jean-Pierre Rosen
2006-06-02 10:27           ` Stephen Leake
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox