Graham Palmer

So following along my line of thought here - using ``` struct UsedChunk { const mepoo::ChunkHeader* chunkHeader; uint32_t current; uint32_t previous; } ``` in the `UsedChunkList` API's would be sufficient...

If it is preferable to you I'm happy to speak about this problem synchronously via some video chat. It is a bit of a high priority issue for us and...

There is also a compromise solution. We could add the plumbing to allow typed endpoints to have fast removal by referencing the insertion index in those custom deleters, but leave...

Ah shoot, realization just dawned on me about a flaw in my proposed solution [here](https://github.com/eclipse-iceoryx/iceoryx/issues/2221#issuecomment-1991643957). We cannot simply store the previous element index in the returned data structure, because the...

Hah, cool. `iox::unique_ptr` supports type erasure unlike `std::unique_ptr` because of the non-templated deleter. Neat. Seems like we really could return a `Sample` for untyped endpoints.

FYI I'm working through an implementation right now. I've gone a different route in refactoring the UsedChunkList and am leveraging the `mpmc_loffli` to make the `UseChunkList` basically a slot map...

Can confirm that using the `mpmc_loffli` works. Updating the used chunk list unit tests to use size 100,000 results in a hang on master, and completes in the snap of...

My intention is to try to run Iceperf to see the impact of the synchronization. If it is too problematic we can always fall back to a simpler slot map...

I think I might also be able to revert my changes to the untyped API's to use the `Smart_Chunk` in favor of returning a struct with the slot map token...

With the experimental API, I assume we still have to maintain the changes to the middleware layers `chunk_reciever`, etc... to support keeping track of the slot map iterator? But then...