async `future` support for every entity waiting on events

[elfenpiff]

Brief feature description

A user may want to receive a sample from a subscriber packed into a future, so that they can consume the sample whenever it is ready. The usage could look like:

    let future_sample = subscriber.async_receive();
    // do stuff here
    println!("received {:?}", sample.await);

Other constructs that are maybe interesting are:

• service discovery - wait until a thing is there or gone
• events - wait for an incoming event
• publisher & listeners - wait for participants

[elfenpiff]

@elBoberido what are your insights on this?

[elBoberido]

@elfenpiff there is an entry on the ekxide roadmap to explore an inter-process executor based on async so this is definitely something we should have. I'm a newbie when it comes to Rust async but I've often read that async is kind of contentious and that one often has to decide whether to have an async API or a non-async one. Nevertheless, we need to explore this.

[stjepangolemac]

This would be very useful 👍

[Sytten]

It is hard to have an API both sync and async, but it is doable if you have traits at the right places with the same primitives. For example diesel has diesel-async which reuses the same primitives but has an async layer for networking.

[elfenpiff]

iceoryx2 provides events to support push notifications so that you are not forced to perform busy waiting, see: https://github.com/eclipse-iceoryx/iceoryx2/tree/main/examples/rust/event

The rough idea is that you use two services, one with a pub/sub and one with an event messaging pattern. Whenever you send your messages via pub/sub, you can signal an event, and the other process will wake up and consume the messages.

This is a bit more manual work but allows you also to be more performant since you can really define your conditions when to trigger across processes. For instance, if you want to trigger only when process P has received 2 messages via service S1 and 4 messages via service S2. With iceoryx (CPP version) we baked this into the publisher, the API was easier to use but with the downside that in the above case process P add false wakeups that cost a lot of performance.

@Sytten @stjepangolemac would this be something that would help you (temporarily) or would you still require an async API?

Nevertheless, we are aware of the need for an async API and it has a high prio on our side. Currently, we are working on feature parity with old cpp iceoryx and C/C++ bindings - this should be finished soon and then we try to revisit async.