Alternative to std::promise and std::future

[hemalbavishi]

Hello,

We are integrating Iceoryx with ara::com for functional safety. As you might be aware that ara::core::future and ara::core::promise used by ara::com is based on std::future and std::promise which is using dynamic memory. Is there any alternate available in Iceoryx which I can use it instead of std::promise and std::future in ara::core types?

Many thanks!

Best Regards,
Hemal Bavishi

[mossmaurice]

Hi @hemalbavishi

Thanks for raising this very good question! In the past few weeks, I created an exemplary binding which is very close to ara::com.

As you can see in types.hpp due to the lack of a exception-free iox::cxx::Future and iox::cxx::Promise, I'm using the STL version.

I know that @MatthiasKillat thought about creating those classes and I would also be interested in implementing those. However, as there was no issue yet, I created one. I'm not sure if this will make it into the C release v3.0.

[hemalbavishi]

@mossmaurice
Thank you for raising ticket. I am very keen to develop cxx::future and cxx::promise in Iceoryx. However, I don't have much idea. If you @MatthiasKillat can suggest some design, I am ready to implement it and share with Iceoryx community. Would it be possible for you to share rough sketch you have it in mind to make this happen?

Best Regards,
Hemal Bavishi

[MatthiasKillat]

@mossmaurice @hemalbavishi I played around with promises and futures which do not use dynamic memory in https://github.com/MatthiasKillat/iceoryx/tree/iox-futures-experimental. However, this is tricky and not finished yet. The main problem is that we have to simulate shared state that would normally reside in dynamic memory. It can be overcome, but there will be (slight) usage restrictions and performance loss (due to additional locks). Maybe there is an entirely different approach which I am not yet aware of.

The experimental implementation still has some races which are not yet solved etc. I plan to do this in the near future (and could raise a PR if it is mature enough). The interface is in future.hpp and very much work in progress (as are the tests, but I need to fix a race in the design before proceeding there).

Now we have to distinguish between emulating std::futures (which this branch does) and having specialized posh futures which could allow us to add some syntactic sugar to request response communication.
Basically they would set up the client/server infrastructure behind the scenes and can be used almost like STL futures. The computation would take place in another process though and would be send by the server. This I did not yet work on but it could also be useful to avoid much request-response boilerplate code. The tricky part is implementing it general and efficiently enough. I talked about this with @elBoberido some while ago.

I believe those are two different issues.

NB: If we can implement cxx::future properly we should also be able to generalize it to cxx::shared_ptr and cxx::shared_future without dynamic memory. This is more difficult because now the state can be shared between an arbitrary number of pointers (not just a promise and a future).

[hemalbavishi]

@MatthiasKillat : I just glanced your code. I will do little bit analyze it more but isn't it a good idea to keep shared_state in a SHM instead of in dynamic memory. But this is only a thought that came into my mind while going through your answer. I am yet to analyze it bit more.