Passing Time via RCI

Passing Time via RCI

[Marc A. Criley]

I would like to pass an entity representing time across an RCI
interface, therefore I need a time type acceptable to the
constraints imposed on RCI units.

Unless I've overlooked something, neither Calendar or Ada.Real_Time,
both being "normal" packages, meet those constraints, and are
therefore unsuitable as providers of the time type.

Do I have to define my own time type?  And write my own time
utilities?  Or do an Unchecked_Conversion from Time to some byte
array I define, pass it, then convert it back?

This seems, uh, silly.  What am I missing?


-- 
Marc A. Criley
Chief Software Architect
Lockheed Martin ATWCS
marc.a.criley@lmco.com
(610) 354-7861

Re: Passing Time via RCI

[Samuel Tardieu]

>>>>> "Marc" == Marc A Criley <marc.a.criley@lmco.com> writes:

Marc> Do I have to define my own time type?  And write my own time
Marc> utilities?  Or do an Unchecked_Conversion from Time to some byte
Marc> array I define, pass it, then convert it back?

That's a bad idea to do an unchecked conversion to an array of bytes,
since it won't work in heterogeneous environments (bytes won't get
swapped in the case of an array, while they should if they represent a
time). You should probably define your own time type.

Marc> This seems, uh, silly.  What am I missing?

You don't transmit pointers accross partitions, because a pointer has
no meaning in a different address space. You should consider that the
same thing happens with absolute times (distributed time is a
well-known concept). You can still transmit durations though.

  Sam
- - --
Samuel Tardieu -- sam@ada.eu.org

Re: Passing Time via RCI

[Marc A. Criley]

Samuel Tardieu wrote:
> 
> >>>>> "Marc" == Marc A Criley <marc.a.criley@lmco.com> writes:
> 
> Marc> Do I have to define my own time type?  And write my own time
> Marc> utilities?  Or do an Unchecked_Conversion from Time to some byte
> Marc> array I define, pass it, then convert it back?
> 
> That's a bad idea to do an unchecked conversion to an array of bytes,
> since it won't work in heterogeneous environments (bytes won't get
> swapped in the case of an array, while they should if they represent a
> time). You should probably define your own time type.

Yeah, Unchecked_Conversion is way down on my list of palatable
solutions, though the network on which it'd be used is homogeneous.
It just strikes me as almost an oversight that I have all these Time
oriented utilities and I can't simply use them because there's no
straightforward way to pass time around.  Another option I've got
is to Split the time, type convert the Year, Month, etc into my
own types, pass these, convert them back to Calendar.Year, etc.,
and use Time_Of to rebuild the time.  And still...

> Marc> This seems, uh, silly.  What am I missing?
> 
> You don't transmit pointers accross partitions, because a pointer has
> no meaning in a different address space. You should consider that the
> same thing happens with absolute times (distributed time is a
> well-known concept). You can still transmit durations though.

With this system, a single process is the master timekeeper and all
other processes are syncing off it.  (Yes, I know about propagation
delays, in this system the time resolution requirements are coarse
enough that it's not an issue.)

I'd thought about using Duration as an offset to a base time, but
I _still_ have to get the base time across, for display purposes.

> 
>   Sam
> - - --
> Samuel Tardieu -- sam@ada.eu.org

-- 
Marc A. Criley
Chief Software Architect
Lockheed Martin ATWCS
marc.a.criley@lmco.com
(610) 354-7861

Re: Passing Time via RCI

[Martin M Dowie]

[snip]
> Yeah, Unchecked_Conversion is way down on my list of palatable
> solutions, though the network on which it'd be used is homogeneous.
> It just strikes me as almost an oversight that I have all these Time
> oriented utilities and I can't simply use them because there's no
> straightforward way to pass time around.  Another option I've got
> is to Split the time, type convert the Year, Month, etc into my
> own types, pass these, convert them back to Calendar.Year, etc.,
> and use Time_Of to rebuild the time.  And still...
[snip]

you mention that its a homogeneous network, but are all nodes on the
network going to be built using the same compiler (even down to
version)? even then, will your compiler assign the same space for
objects of a type exported from a shared package used in different
executables, or is it clever enough to choose different ones if this
would be faster execution within each executable?

we have a similar problem here. we are having to use our own time
package and do all those conversions you talked of, as our 'system real
time' can come from various sources and we have to synch our own
processors with it.

we're also constrained to using a common communications layer that sits
between us and the hardware and have to convert every message into an
array of bytes (this type being provided by the comms layer).

and on top of that we're on a hetrogeneous lan - and endianness also has
to be taken into account!! fun or what? :-)

i doubt there will be any other way of doing this over processor
interfaces other than defining your own (known represenation) types and
doing the conversions, as the standard time types are (with good reason)
deliberately implementation dependant.

if you think of something more ingeneous than all this, please let me
know!

p.s. our stuff is in Ada83, if it makes a difference.
-- 
Martin M Dowie

Re: Passing Time via RCI

[Jean-Pierre Rosen]

Marc A. Criley a écrit dans le message <34D70B78.6503@lmco.com>...
>Samuel Tardieu wrote:
>> 
>> >>>>> "Marc" == Marc A Criley <marc.a.criley@lmco.com> writes:
>> 
>> Marc> Do I have to define my own time type?  And write my own time
>> Marc> utilities?  Or do an Unchecked_Conversion from Time to some byte
>> Marc> array I define, pass it, then convert it back?
>> 
>> That's a bad idea to do an unchecked conversion to an array of bytes,
>> since it won't work in heterogeneous environments (bytes won't get
>> swapped in the case of an array, while they should if they represent a
>> time). You should probably define your own time type.
>
>Yeah, Unchecked_Conversion is way down on my list of palatable
>solutions, though the network on which it'd be used is homogeneous.
>It just strikes me as almost an oversight that I have all these Time
>oriented utilities and I can't simply use them because there's no
>straightforward way to pass time around.  Another option I've got
>is to Split the time, type convert the Year, Month, etc into my
>own types, pass these, convert them back to Calendar.Year, etc.,
>and use Time_Of to rebuild the time.  And still...
>
Why don't you simply pass it as a string ? All  you need is a simple package to convert times to/from strings. Everybody has such a  package (if you don't have it, write it quickly (or I'll send you mine), since it is useful in many occasions).