rotor VS libev

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.

Thank you for this.

I am interested in how concurrency can be represented elegantly and efficiently, so I am interested in how libraries can simplify async and make it easier to reason about and write

The libev and ioring support is great for IO scalability (https://github.com/enki/libev not sure if this is the official repo)

In Python I use the "select" module and use epoll on Linux.

I am currently thinking of designing an API that allows the registration of epoll-like listeners to arbitrary objects, including business objects, so you can efficiently register a listener on multiple behaviours of multiple arbitrary objects.

I wrote an async/await simulation in Java and my scheduler is really simple, it's just a for loop that checks to see if there are any tasks that can progress. I notice the switch_fiber in polyphony must do something similar. This is similar to a yield in a coroutine.

My async/await simulation takes the following program:

  task1:

Also, libev

It's done even now. See ev.h where they do this. Just that you disable GCC's aliasing warning. There's a reason why restrict and aliasing became important to deal with. It wasn't standards that killed it.