libev VS packio

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.

That's not even helpful, as you usually read/write using composed ops and they will interleave anyway. To have an io object that's capable of correctly pipelining multiple concurrent write- or read-operations, you need a custom strand like this: https://github.com/qchateau/packio/blob/master/include/packio/internal/manual_strand.h

packio, it's an async msgpack-rpc or json-rpc library based on boost.asio