Experimental Physics and
Industrial Control System

Jeff Hill <[email protected]> · Wed, 02 Mar 2005 14:55:42 -0700

Hi Kay,

Its worth noting another fundamental difference between the
stringSegment and stream interfaces. A stream is templated
by the token type. The stringSegment assumes that 
all tokens are convertable to type int, but stored in
implementation defined way. When copying between two
stringSegment of the same type no conversion occurs 
and copies are very efficent. When copying between 
different implemenations each element is converted to 
and from type int. Therefore, stringSegment provides a
universal interface to different string implemenations
assuming that there is a universal integer wide code.
With standard streams there would need to be a different
overloaded function in dataAccess for each stream 
template instantiation (character width).

We need to consider that there are many local 
variations in how time and dates are converted to 
strings. I suppose that different countries are also
using different decimal point characters and or 
exponential notation letters? Berhaps thats less 
of an issue. 

So there is also the issue of the C++ 
locale facility. Its quite flexible, seems to provide 
many important benefits, but also complex. 

Since there are conversion functions in the stringSegment 
interface we do not preclude use of the C++ locale facility 
in the implementation. Nevertheless, when becoming dependent
on an implemenation we will need to carefully consider 
this matter. Perhaps, our goal should be that the 
string implemenation - especially the string to numeric
conversions - can be a site replaceable component.

> 
> Back to strings, memory in fixed chunks, and CA:
> In order to have a client and server exchange
> huge strings or custom data types, is it acceptable
> to require a compatible configuration of memory chunk
> sizes?

Its probably a bad idea to require that the client 
and server need to have compatible chunk sizes.

> 
> So is it unthinkable to restrict yourself to a
> memory chunk size that - on vxWorks or RTEMS - will be
configured
> on startup and your strings have to fit in there?
> So EPICS strings won't be limited to e.g. 40 chars.
> On swapping operating systems they are even 'virtually
unlimited',
> and on e.g. vxWorks you can only serve strings that fit within
> one memory chunk?
> 
> That way they don't need to be split across memory blocks,
> and their interface can be C-style to which
> every C++ class library (which of course comes with its custom
> string class) can interface.

The problem here will be storage inefficiency. The protocol 
buffers will tend to use chunk sizes closer to the size of 
Ethernet packets. Most strings will be very small. The 
largest string might be gargantuan (but not for SNS PV names of 
course).

Trying not to repeat mistakes I have made in the past, my 
inclination is to design the stringSegment interface
to not preclude high performance implemenations based on 
non-contiguous fixed sized blocks.

Jeff

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System