Re: Ada Annex E (Just curious :-)

["Marin David Condic" <marin.condic.auntie.spam@pacemicro.com>]

"Ted Dennison" <dennison@telepath.com> wrote in message
news:FONo6.1740$45.2180@www.newsranger.com...
> I'd like to have an answer to that one too. I don't think its really
usable for
> a hard real-time system, as there is no way to guarantee response time. In
fact,
> its tough to achieve this with any networking software. You pretty much
have to
> control the transmission method used for everything from the application
layer
> down to the physical layer.
>
I would agree that the lack of predictable latency makes it of somewhat
dubious value for realtime systems. It would seem that it might be useful if
you had some form of background workload that you could pass off to another
processor and it didn't matter if the work got done in some predictable
timeframe. (For example, you might have some kind of diagnostics performed
on your realtime data that needed to be done as often as possible, but just
to issue some sort of display info to the operator. An unusual delay might
not be a big deal.)

Or possibly if you had multiple processors in a system that controlled
different hardware? Say, having a graphics processor to which you performed
RPC's to get certain things rendered? (Of course, this would require either
a very standardized processor/communications-interface or you'd never get
the compiler modified to suit the environment. :-)

It would seem that it might be useful for either computationally intensive
applications that lend themselves to distribution (I've seen it done with
CFD calculations) or database systems such as, say, teller machines that
want to verify a bank balance with a central computer before allowing a
withdrawal.

Of course, one could achieve any of these things by other means than having
an RPC. One could pass messages through pipes or TCP/IP sockets or any other
means & establish some kind of protocol between the applications. However,
it seems (all other things being equal - as seldom they are ;-) that an RPC
might be more invisible to the application programmer than other solutions
might be. ("Here you go: Just call this procedure and don't worry about the
rest. We'll handle all the distribution for you...")

> >is "cool", easy to use and effective... all I need now is an application
> >that would benefit significantly from it.
>
> I'm with you.

Maybe its just the application domain you are usually involved in? Remember,
it is a "Special Needs Annex" and may just be the kind of thing that is more
common for a different problem domain. (I'd think it would be used heavily
in business applications where there was at most a soft-realtime
requirement.)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/