[#504] slotmap

[elfenpiff]

Notes for Reviewer

The SlotMap is required to store multiple data segments and fixed indices so that the senders and receivers of a shared memory communication can manage them (add/remove at runtime). When a sender runs out of memory a new data segment is added at the same index by every participant and this index is part of the memory offset the sender delivers to the receiver via the zero copy channel.

The RelocatableContainer concept had to be cleaned up a bit in order to implement the SlotMap.

• The "base" class always has the prefix details::Meta**
• via type aliases and generic pointer parameters the **, Relocatable** types are defined
• the FixedSize** contains a Relocatable** and provides the memory

Example: details::MetaQueue (implementation). Queue (runtime fixed-size heap version), ReloctableQueue (runtime fixed-size shared memory version), FixedSizeQueue (compile-time fixed-size shared memory version)

The ReloctableContainer trait contained a new() method where a relative position to the memory had to be provided. This was removed since it was too error prone to use. The BumpAllocator in combination with the already existing new_uninit + init(allocator) approach was used to replace it.
This is relevant for all FixedSize** versions.

Since Rust does not allow any compile time const operations we could not use in the fixed size version pre-allocated memory in the form of

struct FixedSizeVersion<const CAPACITY: usize> {
  state: RelocatableVersion,
  memory: [u8; RelocatableVersion::const_memory_size(CAPACITY)], // not supported
}

To make the code somehow readable, the actual payload members where listed after the RelocatableVersion in the struct definition.

Also, the RelocatableVec had to be refactored to follow the details::MetaVec, Vec, RelocatableVec, FixedSizeVec pattern so that it could be used in the implementation of the SlotMap.

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

Closes #504

[codecov]

Codecov Report

Attention: Patch coverage is 81.65007% with 129 lines in your changes missing coverage. Please review.

Project coverage is 79.08%. Comparing base (810fb87) to head (a5f1e64).
Report is 29 commits behind head on main.

Files with missing lines	Patch %	Lines
iceoryx2-bb/container/src/slotmap.rs	77.08%	77 Missing ⚠️
iceoryx2-bb/container/src/vec.rs	77.63%	51 Missing ⚠️
iceoryx2-bb/container/src/queue.rs	96.55%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #505      +/-   ##
==========================================
- Coverage   79.22%   79.08%   -0.14%     
==========================================
  Files         200      201       +1     
  Lines       23765    24139     +374     
==========================================
+ Hits        18828    19091     +263     
- Misses       4937     5048     +111     

Files with missing lines	Coverage Δ
iceoryx2-bb/elementary/src/bump_allocator.rs	86.36% <ø> (ø)
iceoryx2-bb/elementary/src/owning_pointer.rs	96.00% <ø> (ø)
iceoryx2-bb/elementary/src/relocatable_ptr.rs	100.00% <ø> (ø)
iceoryx2-bb/lock-free/src/mpmc/bit_set.rs	95.23% <100.00%> (-0.14%)	⬇️
iceoryx2-bb/lock-free/src/mpmc/container.rs	96.38% <100.00%> (-0.28%)	⬇️
iceoryx2-bb/lock-free/src/mpmc/unique_index_set.rs	92.96% <100.00%> (-0.30%)	⬇️
iceoryx2-bb/lock-free/src/spsc/index_queue.rs	86.50% <100.00%> (-0.46%)	⬇️
...ck-free/src/spsc/safely_overflowing_index_queue.rs	94.61% <100.00%> (-0.19%)	⬇️
iceoryx2-bb/memory/src/pool_allocator.rs	94.80% <100.00%> (+0.23%)	⬆️
iceoryx2-cal/src/shared_memory/common.rs	86.38% <100.00%> (ø)
... and 10 more

... and 5 files with indirect coverage changes

---- 🚨 Try these New Features:

• Flaky Tests Detection - Detect and resolve failed and flaky tests

[elBoberido]

Looks good in general.

[elBoberido]

Why not just use a ManuallyDrop<T> instead of an Option<T> if the value must always be available?

... okay, after some thinking, it would need to be a ManuallyDrop<MaybeUninit<T>> which makes it more cumbersome to use.

[elBoberido]

I think this is something that could easily be created with a proc macro. No so sure about implementing default via the proc macro. That might be more difficult but at least the struct members would automatically be kept in sync.

[elfenpiff]

You are maybe right. Sooner or later we have to revisit the relocatable container concept and then we introduce something like this here. Currently, I would stick to the current approach since it is used also in the other containers - but I agree, I also do not like it at all!

[elBoberido]

I'm not sure if there is currently another way to do it, except having a proc macro that calculates the memory size and adds a buffer: [u8; N] member to the struct. Anyway, without a proc macro the current way is less cumbersome and with the proc macro it doesn't really matter since it's hidden from the developer.

[elBoberido]

Looks good. My advice with inpsect tuned out to not work with Rust 1.75.