Boost.Asio VS libev

Indeed looks like it, strand_executor_service.hpp is using a Mutex internally (otherwise it wouldn't make sense to me).

as a side note, Asio is also released as an independent library without the boost stuff https://think-async.com/Asio/

Now that vinniefalco is going to kill off the asio standalone (see deprecate standalone ) and only support boost what would people then recommend to switch over to.

The ASIO framework can be found at https://think-async.com/Asio/ and the relevant license for its use is included in the GitHub repository in the Vendor/licenses directory.

The library is found at https://think-async.com/Asio/.

Asio Extracted from the much bigger Boost C++ library, it's apparently a really good networking library. As a bonus it also handles async / threads. Here's a really good video tutorial by OneLoneCoder

Yes: https://github.com/chriskohlhoff/asio/blob/master/asio/include/asio/coroutine.hpp

Here's the main contributor to Asio. I looked at Asio's repository and this was the first guy.

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.