eclipse-iceoryx / eclipse-iceoryx/iceoryx
Option to retain samples on publisher side after publishing
- Dominant language
- C++
- Stars
- 2.2k
- Forks
- 492
- Avg merge
- 18h 57m
- Merged PRs (30d)
- 1
Description
## Brief feature description
Currently after loaning a sample (memory chunk) on publisher side we have two options
1. publish it
2. return it to the publisher without publishing
After publishing the lifetime of the sample is not ensured anymore, once it was consumed by any subscriber or a new sample is loaned on this publisher.
In some cases (here in particular for a zero-copy optimization in cyclonedds) it is needed to extend the lifetime of the sample.
Additional API shall ensure this is possible by having an additional publish call with this option.
Note that changing existing API is not an option here as it will break 1.0, especially on the C-API where we do not have default arguments.
## Detailed information
Due to the way RouDi keeps track of samples to potentially cleanup when applications crash, a cache for those samples retained will be necessary at publisher side.
This means we cannot solve this using a sample/chunk alone due to
1. unavailability of the current refcount if we only have the chunk pointer
2. the fact that we need to clean up memory leaks when applications die and Roudi does not keep track of samples on a per process basis (but on a per port basis which in turn belong to processes)
Note that this kind of cache has a downside of requiring inefficient (brute-force) searches which is problematic for larger cache sizes. We will also need some kind of upper limit of how many samples can be retained this way (due to a static memory model).
## Implementation strategy
TBD
Contributor guide
Research direction
Start by tracing the publisher loan, publish, and return APIs, then examine RouDi’s per-port sample cleanup tracking. Define how a retained-sample cache, an upper bound, crash cleanup, and the additional publish option should work; the issue provides no file or test entry points, so the design must be settled before implementation.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp
- Domain
- backend-api-design, distributed-systems, performance
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100