eclipse-iceoryx / eclipse-iceoryx/iceoryx

Option to retain samples on publisher side after publishing

Open
#761 0 comments 0 reactions 0 assignees View on GitHub
enhancement
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.