Open elfenpiff opened 7 months ago
@elBoberido Oh I think this is an important one and needs to be addressed quickly. This morning I remembered that you told me once that you add this feature always right from the beginning when you write serialization code.
If you mean something like having a SHM_API_VERSION
in each shared memory file, then yes. If you want to add it to each struct, e.g. a vector
then maybe not :sweat_smile:
Oh did you version the config file?
Problem
When two
elkodon_cal
constructs interact with each other, we need to add some initial versioning information to ensure that not to incompatible versions of the same constructs are interacting. This could lead to undefined behavior and hard to unravel bugs.They could be, for instance incompatible since the member order of shared management constructs has changed or members have been added/removed. Or the internal communication protocol was updated.
Solution
Introduce a
const SHM_API_VERSION: u64
constant insideelkodon_cal
, that must be checked before any of these constructs start to interact on an ipc level. Constructs that use shared memory could add this constant to the beginning, as the first value, to their shared memory. If the construct does not use shared memory, one could create a file and store the number value is binary, or human-readable value, in there.