GithubHelp home page GithubHelp logo

Comments (5)

elfenpiff avatar elfenpiff commented on August 27, 2024

@elBoberido what are your insights on this?

from iceoryx2.

elBoberido avatar elBoberido commented on August 27, 2024

@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.

from iceoryx2.

stjepangolemac avatar stjepangolemac commented on August 27, 2024

This would be very useful 👍

from iceoryx2.

Sytten avatar Sytten commented on August 27, 2024

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.

from iceoryx2.

elfenpiff avatar elfenpiff commented on August 27, 2024

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.

from iceoryx2.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.