[#349] Add service name generator to be able to run tests concurrently

[elfenpiff]

Notes for Reviewer

Fixes some parts of the problem but not everything

Pre-Review Checklist for the PR Author

1. Add sensible notes for the reviewer
2. PR title is short, expressive and meaningful
3. Relevant issues are linked in the References section
4. Every source code file has a copyright header with SPDX-License-Identifier: Apache-2.0 OR MIT
5. Branch follows the naming format (iox2-123-introduce-posix-ipc-example)
6. Commits messages are according to this guideline
   • Commit messages have the issue ID ([#123] Add posix ipc example)
   • Commit author matches Eclipse Contributor Agreement (and ECA is signed)
7. Tests follow the best practice for testing
8. Changelog updated in the unreleased section including API breaking changes
9. Assign PR to reviewer
10. All checks have passed (except task-list-completed)

Checklist for the PR Reviewer

• Commits are properly organized and messages are according to the guideline
• Unit tests have been written for new behavior
• Public API is documented
• PR title describes the changes

Post-review Checklist for the PR Author

1. All open points are addressed and tracked via issues

References

Relates to #349
Closes #475

[orecham]

Had to do the exact same thing in the RMW 😆 .

[elfenpiff]

When set_log_level(LogLevel::TRACE) is active one test fails with this:

ServiceEventTest/0.open_or_create_service_does_exist

      353 [D] Builder { storage_name: FileName { value: FixedSizeByteString<255> { len: 40, data: "26380db3f2d1d21a17def8273faec2e5097cf3e2" } }, supplementary_size: 0, ha
s_ownership: false, config: Configuration { suffix: FileName { value: FixedSizeByteString<255> { len: 8, data: ".dynamic" } }, prefix: FileName { value: FixedSizeByteStrin
g<255> { len: 5, data: "iox2_" } }, path: Path { value: FixedSizeByteString<255> { len: 14, data: "/tmp/iceoryx2/" } }, _data: PhantomData<iceoryx2::service::dynamic_confi
g::DynamicConfig> }, timeout: 500ms, initializer: , _phantom_data: PhantomData<iceoryx2::service::dynamic_config::DynamicConfig> }
| Failed to open  since the version number was not set - (it is not initialized after 500ms).

Which then lead to a failure when opening the dynamic service info and then the builder assumes the services is in a corrupted state.
This comes only up with bazel, never occurs with cmake or with Rust (which has the same test)

The mechanism that seems to fail here is the concurrent dynamic storage creation/opening for the ipc::Service. To support concurrent creation/opening the creation must somehow tell the opener that the initialization is still in progress. This is done with two mechanisms:

1. The permission is set to write only as long as the memory is initializing.
2. The first 8 byte (or so) are zeroed by the OS and
3. when the initialization is finished the version number is written.
4. The permission is set to read/write

When the opener comes it first checks if it has read/write permissions, if not, initialization is still in progress. If it has read/write permissions it also checks the version number. If it is zero, still in initialization, if not zero it must match its own local version number.

[elfenpiff]

Okay, there was an actual bug in the dynamic storage posix shared memory implementation. When the creation process is still initializing the memory, the opener takes a COPY of the version number instead of a pointer to it and checks it until it becomes non-zero.

The thing is, this is a bug that should only occur on OSes that do not support adjusting the permissions of the shm during runtime like Mac OS and Windows and not linux.

And this also does not fix the failing test

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 78.92%. Comparing base (cd27eee) to head (b3dfa90).
Report is 27 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #472      +/-   ##
==========================================
- Coverage   78.93%   78.92%   -0.01%     
==========================================
  Files         197      198       +1     
  Lines       23637    23627      -10     
==========================================
- Hits        18657    18647      -10     
  Misses       4980     4980              

Files with missing lines	Coverage Δ
iceoryx2-bb/elementary/src/package_version.rs	87.50% <100.00%> (+17.50%)	⬆️
...yx2-cal/src/dynamic_storage/posix_shared_memory.rs	89.29% <100.00%> (-0.25%)	⬇️

... and 4 files with indirect coverage changes

[xieyuschen]

just curious, do we have a specific version convention? not sure why we didn't use the semver, which is popular in rust. so in the future we may have beta, alpha or rc versions.

https://crates.io/crates/semver

[elfenpiff]

In general we try to be very cautious to introduce external crates. For any other project I would agree with you but iceoryx2 shall be certified as ASIL D according to ISO26262 which is the highest safety standard in the automotive world.

This requires 100% MC/DC coverage for every line of code. Every test must be covered by a requirement, we need detailed architecture documents and documentation, a safety manual and so on.

So, every dependency we introduce must satisfy all of this! No exception. But actually, nearly none of them does it, and it is a challenge to do it. We have a strategy in place how to solve this but one of the key factors is - try to avoid external crates as much as possible.

Another answer we need to find is, how to handle or prevent supply chain attacks.

So in light of all of this, we try to be very cautious with external dependencies since the more we have the more work we have to do in the near future.

[xieyuschen]

ASIL D according to ISO26262 ... how to handle or prevent supply chain attacks.

understood, quite a bit different from the normal project. thanks for your explaination:)

[xieyuschen]

looks like it deserves a unit test:)

[elBoberido]

Having a script taking care of setting the version number in all known locations would be helpful. I'll add it to my todo list :)