Asynchronous Server in C++

Question

We are looking to develop an asynchronous server in C++. We are coming from C#, which has built-in support for async-await networking. However, with C++ it appears as if it is basically mandatory to use ASIO, other you're out of luck.

I am wondering if there is are any other options besides ASIO if we want to make an asynchronous server in C++? It would be preferable not to have to rely on a third party library.

• amon: Boost is effectively part of the standard library, no reason to avoid it. In the past, I worked on a project where Boost was not an option due to technical reasons, and used Tntnet which supports an event loop. C++20 integrates language-level support for async/await, but that's useless without a library that provides an executor. All in all, C++ does not have as good async support as C#. If you don't want to use Boost.Asio, you'll probably want to stick to a classic threadpool instead. And have you considered not using C++? E.g. async Rust is also awful, but 1000× better than with C++.
• Stack Exchange Broke The Law: There is certainly whichever platform-specific library ASIO uses on your platform.
• Jerry Jeremiah: Related: stackoverflow.com/questions/39106863/…
• Jerry Jeremiah: This might be what you are looking for: github.com/Amanieu/asyncplusplus
• Jerry Coffin: You might find libuv interesting.

Answer 1

with C++ it appears as if it is basically mandatory to use ASIO

not at all. That's just a cross-platform library which gives you nice, portable code.

You can always code directly to your platform APIs (admittedly on Windows I have no idea what those are). Or, you can use std::async with futures/promises to wrap synchronous I/O (or packaged_task with your own threadpool, or whatever).

The point is there's plenty of code out there doing both asynchronous and non-blocking synchronous multiplexing I/O without using ASIO or Boost.Asio. It's just either platform-specific, or uses another 3rd-party library, or contains an equivalent amount of platform abstraction code internally.

It would be preferable not to have to rely on a third party library.

From the language point of view, your platform APIs are 3rd party. Since you definitely need to use something that isn't part of the standard library, you might just as well use the nice portable one.

• Stack Exchange Broke The Law: On Windows it would be I/O Completion Ports. You issue one or more "overlapped" read/write operations and then you call the "wait for something to finish" function (GetQueuedCompletionStatus). Then you process the result of whatever finished, optionally issue more operations, and repeat.