如何在c++中使用协程实现一个异步的RPC客户端？ (C++20 Coroutines)

c++20协程本身不提供异步I/O能力，必须与io_uring、epoll或Boost.ASIO等底层异步设施结合才能实现真正的异步rpc；标准库无awaitable I/O支持，socket需设为非阻塞并由事件循环驱动，协程仅负责执行流挂起/恢复。

直接说结论：C++20 协程本身不提供异步 I/O 能力，也不能直接发网络请求；它只负责挂起/恢复执行流。要实现异步 RPC 客户端，你必须把协程和底层异步 I/O（如 io_uring、epoll、或第三方库如 libuv/Boost.ASIO）胶合起来——否则协程只是“假异步”，会阻塞线程。

为什么不能只靠 co_await 发 http 或 gRPC 请求？

C++20 标准库至今（C++23 仍未加入）没有提供任何异步 I/O 的 awaitable 类型。像 std::net 这样的提案被多次推迟。这意味着：

• co_await 后面必须是自定义的 awaitable 类型，不能直接写 co_await http_client.send(req)
• 所有 socket 操作（connect、send、recv）仍需通过系统调用完成，而这些调用默认是阻塞的
• 若在协程里调用阻塞 socket 函数，整个线程会被卡住，协程失去意义

如何让协程真正异步等待 socket 事件？

核心思路是：把 socket 设为非阻塞模式，用事件循环监听可读/可写状态，再包装成 awaitable。以 Boost.ASIO 为例（它已原生支持 C++20 协程）：

struct rpc_call {     asio::ip::tcp::socket sock;     asio::steady_timer timer;      rpc_call(asio::io_context& ctx) : sock(ctx), timer(ctx) {}      asio::awaitable call(std::string_view method, std::string_view payload) {         try {             co_await asio::this_coro::executor;             // 建立连接（非阻塞 connect + async_wait）             sock.open(asio::ip::tcp::v4());             sock.set_option(asio::ip::tcp::socket::non_blocking_io(true));             auto ep = asio::ip::tcp::endpoint(                 asio::ip::make_address("127.0.0.1"), 8080);             sock.async_connect(ep, [](const boost::system::error_code&) {});             co_await sock.async_wait(asio::ip::tcp::socket::wait_write, asio::use_awaitable);              // 发送请求（需手动处理 partial write）             std::string req = "POST /" + std::string(method) + " HTTP/1.1rn";             co_await asio::async_write(sock, asio::buffer(req), asio::use_awaitable);              // 接收响应（需处理 header/body 分离、EOF 等）             std::array buf;             size_t n = co_await sock.async_read_some(asio::buffer(buf), asio::use_awaitable);             co_return std::string(buf.data(), n);         } catch (const std::exception& e) {             co_return "ERROR: " + std::string(e.what());         }     } };

注意：asio::async_write 和 asio::async_read_some 返回的是标准 awaitable，可直接 co_await；但你要自己处理协议解析、粘包、超时、重连等——RPC 不是裸 socket。

立即学习“C++免费学习笔记（深入）”；

绕过 Boost.ASIO：手写最小 awaitable 需要什么？

如果你坚持不用 Boost，想从零封装 epoll + 协程，关键组件有三个：

• 一个全局 epoll_fd 和事件循环线程（运行 epoll_wait）
• 每个待等待的 socket 绑定一个 awaitable 对象，含 await_ready()、await_suspend(coroutine_handle)、await_resume()
• await_suspend 中注册该 socket 到 epoll，并保存 coroutine_handle 到哈希表；事件就绪时从哈希表取出 handle 并 resume()

难点不在协程语法，而在：如何安全地在多线程间传递 coroutine_handle；如何避免 epoll_ctl(EPOLL_CTL_DEL) 时协程已销毁；如何统一管理超时和取消。这些正是 Boost.ASIO 和 libexecstream 已解决的问题。

RPC 协议层怎么跟协程对接？

别在协程里解析 Protobuf 或 jsON。正确做法是分层：

• 底层：transport_layer 提供 awaitable send(bytes) 和 awaitable recv()
• 中间：rpc_encoder 将 request Object 序列化为 bytes，并将 bytes 反序列化为 response object
• 上层：用户 API 是 awaitable user_service->GetProfile(int64_t id)

这样协程只感知“发送”和“接收字节流”，协议细节被隔离。gRPC 的 grpcpp 目前不支持 C++20 协程（截至 v1.60），所以多数生产项目仍用回调或 std::future 包装；若真要协程化，得自己桥接 CompletionQueue 事件到 awaitable。

最易被忽略的一点：协程栈默认很小（可能仅几 KB），而 RPC 请求/响应可能带大 payload 或深层嵌套结构体。务必用 std::coroutine_traits::promise_type::get_return_object_on_allocation_failure 或显式分配堆内存的 promise，否则大对象序列化时可能栈溢出崩溃。