Re: ICE and TIPC

[Andrew Johnson <anj@aps.anl.gov>]

Kay-Uwe Kasemir wrote:
> I suggest _not_ to allow con-contiguous storage.
> I cannot imagine a server that keeps his
> strings in segments.

I can; I am considering an implementation of variable length strings 
that does not require the reallocation and copying of data as the string 
is extended.  This would use a fixed allocation size block, and chain 
these blocks together as needed to make up the complete storage for the 
string.

> I understand why a network layer will _receive_
> the data in pieces, but that's a problem of the
> network layer.
> All communications layers that I have seen so
> far hide that detail from me.
> With the proper environment variable configuration,
> even CA V3 hands me the complete dbr_ctrl_double
> for huge arrays,
> so why obfuscate the V4 data access in order to
> support non-contiguous data?

Any API that is designed to support segmented data can also support 
contiguous data with no changes.  An API that requires contiguous data 
cannot be used with segmented data without copying all the data segments 
into a contiguous buffer first, thus requiring extra memory and reducing 
performance.

Eric Norum has an R3.14 IOC with very limited RAM that uses a waveform 
record to allow its flash eprom to be reprogrammed, but his memory 
requirements are such that he can only fit one waveform buffer in 
memory.  If we require another copy of the data this IOC would probably 
not be able to fit in memory.

Since we're designing the APIs and they will hide all of the details 
from user code, why would we make them less flexible?

- Andrew
--
Podiabombastic: The tendency to shoot oneself in the foot.