cpp-ipc
iceoryx
| cpp-ipc | iceoryx | |
|---|---|---|
| 1 | 10 | |
| 1,607 | 1,517 | |
| - | 3.3% | |
| 6.1 | 9.8 | |
| about 2 months ago | 6 days ago | |
| C++ | C++ | |
| GNU General Public License v3.0 or later | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
cpp-ipc
-
What are the "best practices" or "better design patterns" for posting message from one thread to others?
I'm working on a complex c++ project for my company these days. First, I need to pass 5 different types of messages (and attached data) from Process A to Process B. I use cpp-ipc and it works fine. And in Process B, there is one thread (called thread b) which is responsible for receiving those messages and "posting" them to other threads. I can't determine (and of course, don't know) the good solutions. My current idea is to use 5 concurrent queues for the 5 types of message. When thread b receives a message, it pushes the message to a queue, and other threads take the message from the queue. pseudocode example:
iceoryx
-
Show HN: Comprehensive inter-process communication (IPC) toolkit in modern C++
Also, when you want to perform some access control with access rights, you have to face sid— and ace-strings - oh they are fun. And, of course, there are all the nasty details; for instance, Windows defines macros that lead to compilation failures since they collide with internal naming. Take a look at this here, maybe it makes your efforts less painless: https://github.com/eclipse-iceoryx/iceoryx/blob/master/iceor...
You could reuse the iceoryx platform layer that enables iceoryx to run on every platform from qnx, linux, freertos, mac, windows. Maybe it can help you as well: https://github.com/eclipse-iceoryx/iceoryx/blob/master/doc/w...
-
Flow-IPC: Open-Source Toolkit for Low-Latency Inter-Process Communication in C++
Does the schema help a lot? For C++ you can get very fast without, for example with IceOryx https://github.com/eclipse-iceoryx/iceoryx
In contrast to Cap'n'Proto you get compiler optimized struct layout as benefit from using raw structs. Benchmarks are here https://iceoryx.io/v2.0.2/examples/iceperf/
- IPC communication between rust, c++, and python
-
iceoryx v2.0.0 released - a true zero-copy C++ middleware
full release notes: https://github.com/eclipse-iceoryx/iceoryx/blob/master/doc/website/release-notes/iceoryx-v2-0-0.md
-
Shadesmar: Fast C++ IPC using shared memory
True, a better comparison for Shadesmar would be with libraries like iceoryx and alephzero.
-
Announcing Eclipse iceoryx 1.0.0
This is the tracking issue for Windows support https://github.com/eclipse-iceoryx/iceoryx/issues/33
What are some alternatives?
Osiris - Free and open-source game hack for Counter-Strike 2, written in modern C++. For Windows and Linux.
cyclonedds - Eclipse Cyclone DDS project
polybar-dwm-module - A dwm module for polybar
eCAL - Please visit the new repository: https://github.com/eclipse-ecal/ecal
shadesmar - Fast C++ IPC using shared memory
ecal - 📦 eCAL - enhanced Communication Abstraction Layer. A high performance publish-subscribe, client-server cross-plattform middleware.
filesystem - An implementation of C++17 std::filesystem for C++11 /C++14/C++17/C++20 on Windows, macOS, Linux and FreeBSD.
alephzero
ultimatepp - U++ is a C++ cross-platform rapid application development framework focused on programmer's productivity. It includes a set of libraries (GUI, SQL, Network etc.), and integrated development environment (TheIDE).
rmw_iceoryx - rmw implementation for iceoryx
v6d - vineyard (v6d): an in-memory immutable data manager. (Project under CNCF, TAG-Storage)
areg-sdk - AREG is an asynchronous Object RPC framework to simplify multitasking programming by blurring borders between processes and treating remote objects as if they coexist in the same thread.