Extend API for better FFI handling of Samples

[elBoberido]

In #61 a request for an API for better FFI handling of Samples was requested by @phil-opp. The approach turned out to not be sound with the constraints of the iceoryx publisher.

An alternative proposal was to introduce a RawSample.

from here

Thanks! Maybe a RawSample type that wraps a *mut T together with a std::thread::ThreadId would work? We could then create a unsafe publish_raw method that compares the thread ID to guard against publish operations from the wrong thread. We probably want to guard against publishing the sample on a different publisher too?

and from here

Yes, this should work. I'm not sure if we need the thread ID. One could wrap the publisher in a mutex and then it would be save to publish from multiple threads. I have to think more about this. I like the idea with the RawSample though. I think that could be introduced in the iceoryx-sys crate. Currently raw pointer are used but I'm not happy about that. I wanted to use NotNull but some API calls I need are only in nightly available. The RawSample would fix this and could also be used in places I use a Box<T> which must be released into a raw pointer to not call drop. Ideally ´ManuallyDrop´ could be used but again, missing API.

[elBoberido]

@phil-opp currently I'm leaning towards adding an into_raw associated functioon to SampleMut which would consume the sample and return a RawSample. The RawSample would take the ownership but wouldn't release it on drop, resulting in a memory leak. The user would need to either call Publisher::publish_raw or Publisher::release_raw. What do you think?

[elBoberido]

@elfenpiff you might also be interested in this discussion

[elfenpiff]

@elBoberido thanks for pinging me.

Maybe a RawSample type that wraps a *mut T together with a std::thread::ThreadId would work? We could then create a unsafe publish_raw method that compares the thread ID to guard against publish operations from the wrong thread.

This would work but also would put a burden of error handling on the user which we could avoid by a better design I think.

We probably want to guard against publishing the sample on a different publisher too?

The more I think about this the more I think that this is the samples responsibility. It should not be publisher->publish(sample) it should be sample->publish() and on drop the sample is dismissed.

So for this particular problem I would go for the RawSample with into_raw() and then the user has to know what they are doing.

Also for this idea:

One could wrap the publisher in a mutex and then it would be save to publish from multiple threads.

I think this is not so easily implementable. The SampleMut holds a reference to the Publisher so we would require here a reference to a Mutex<Publisher> and then we would have 3 sample variations, mut/const and threadsafe mut. But we could introduce a Publisher trait and keep a reference to a &'a dyn Publisher inside the sample?! This way the sample does not care where it comes from and knows how to publish itself - but thread-safety etc is then the publishers job.

[elBoberido]

@elfenpiff the problem with the sample publishing itself is the lifetime of the publisher. The sample would need to hold at least a weak reference to the publisher which would be upgraded when the sample wants to publish. This could work but needs some work on the C++ side.

The idea with a Publisher trait could work. There could be two types of publisher, one only for single threaded use cases and one for multi-threaded. The multi-threaded one would provide samples which are Send but with the additional costs of having a mutex. This might be something for the long run and the RawSample could be an intermediate solution.