rotor VS libunifex

If your architecture fits into inter-process messaging, i.e. spawn threads which do similar or different tasks and inform each other via messages, try to use actor framework, i.e. rotor (disclaimer: I'm the author). If there is a need to expand messaging even more, i.e. across the network, you can try to use caf, which provides that facility out of the box.

What you achieved, is handlers decoupling, i.e. when one handler knows nothing about other handler, which leads to good application testability. However, with standard promise/future bases messaging, if performance matters (and it usually does, otherwise why use C++?), i doubt that your implementation overwhelms the performance of specialized actor libraries, like sobjectizer ("batteries included" actors toolbox) or rotor (DIY-like actor constructor set; disclaimer: I'm the author of it).

I have been reading the documents from Boost.fibre and Boost.Signals2 which I could use, maybe ASIO for async. I also checked ZeroMQ (this seems to be more or less "only" for networking), Copper and Rotor. If this were just a simple MCU project I would just take the FreeRTOS and would have everything I need. Now I'm just lost how to structure my code / how to realize my main loop.

I would like to present my project rotor, which is event loop friendly C++ actor micro framework with Erlang-like microframework with supervising capabilities.

rotor actor library (I'm the author) was designed to solve similar problem, which I named "actor intrusiveness", when almost every piece of code should be written in form of actor, and, the working threads, which spin actors, are out of your control.

PS. I'm the author of rotor framework )

May be actor frameworks like caf, sobjectizer or rotor is something, that you are looking for.

I'm curious what led you to this conclusion. If you ran into scalability issues with its static_thread_pool, then that's a known issue. If it's something else, the authors (of which I'm one) would love to know.

Instead of calling add_executable you will call add_library. Here is a (only moderately complicated) production example of a library that can be built standalone (along with tests and example executables), or as a subproject, where it builds only the library

My original thought was to build my DDS implementation on top of libunifex in anticipation for standardization: https://github.com/facebookexperimental/libunifex

I'm trying to understand how to work with the proposed executors in a project, but after watching Eric Niebler's cppcon talks (https://youtu.be/xLboNIf7BTg) and looking at the libunifex examples (https://github.com/facebookexperimental/libunifex/tree/main/examples) I still have a hard time wrapping my head around how to employ the sender/receiver pattern in a larger project.

You have coroutines in C++20 but there is also the executives proposal that's making it's way into C++23 that is available as a library under the name unifex that only requires C++14

Asio-grpc makes exactly that possible by providing an Asio execution_context compatible interface to the CompletionQueue. It supports all types of RPCs (including generic ones), completion tokens, cancellation, as well as libunifex sender/receiver (if you want to try out what might become std::execution). The latest release (v1.7.0) also introduced a GrpcStream class for writing Rust/Golang select-style code.

P2300: they are trying to standardize facebookexperimental/libunifex

All the network handling for Instagram and all other Meta apps on all platforms is handled by their own C++ library https://github.com/facebookexperimental/libunifex.

This. I'd also like to mention libunifex. It's entirely based on tag_invoke and is a testament as to how much power it actually provides. On the other hand, it also proves how cumbersome it is to define CPOs with tag_invoke. But IMO it's a lot better than anything else anyone has ever created, and users usually don't need to define new CPOs, only library writers do, so there's that.

A work in progress implementation of the library: https://github.com/facebookexperimental/libunifex