c++ libunifex协程库 c++如何使用facebook的unifex进行异步编程-C++-PHP中文网

unifex::async_scope是异步任务生命周期管理的核心，自动等待所有子任务完成，避免悬空；必须用spawn()而非直接co_await顶层sender，join()用于测试，生产环境宜用cleanup()+co_await+when_all。

c++ libunifex协程库 c++如何使用facebook的unifex进行异步编程

不手动管理协程对象的生命周期，unifex::async_scope 就是唯一靠谱的选择。它自动等待所有挂起子任务完成，避免悬空或提前析构。

常见错误现象：std::terminate 或内存访问违规，往往因为 unifex::just() 启动的任务没被 async_scope 持有，而外层作用域已退出。

必须用 scope.spawn() 而非直接 co_await 顶层 sender（否则任务脱离管理）
scope.join() 是阻塞等待，适合测试或主函数末尾；生产环境建议用 scope.cleanup() + co_await 配合 unifex::when_all
不要在 async_scope 析构后调用 spawn() —— 它不负责线程安全，多线程并发 spawn 需额外同步

Facebook unifex 不提供类似 std::future 的“取值即阻塞”接口，所有计算必须通过 sender/receiver 组合子编排。最常用的是调度 + 变换模式。

使用场景：从线程池派发 IO、转换结果类型、错误映射。

unifex::schedule() 返回的是一个 sender，不是 executor 对象本身；传入的是 scheduler（如 unifex::inline_scheduler 或自定义线程池 scheduler）
unifex::then() 的 lambda 参数必须返回可转为 sender 的东西，不能直接 return 值（会编译失败：no matching function for call to ‘then’）
若需传递异常，用 unifex::upon_error()，别依赖 lambda 内 try/catch —— receiver 的错误路径是独立通道

示例：

C++ Code Review Master

组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。

下载

auto work = unifex::then(
    unifex::schedule(my_thread_pool),
    []() -> int { return 42; }
);
// 注意：此时 work 还没执行，只是定义了计算图

二者都生成 sender，但触发时机和资源占用完全不同：unifex::task 是 lazy 的（仅 co_await 时才启动），unifex::just 是 eager 的（构造即准备就绪）。

容易踩的坑：用 unifex::just(std::move(obj)) 传右值，在 sender 被拷贝多次的组合过程中，obj 可能被 move 多次，导致未定义行为。

unifex::task<t></t> 应该用于封装可能含 suspend/resume 的逻辑（比如带 co_await 的函数），本质是 coroutine wrapper
unifex::just() 适合纯数据转发或 trivial 计算，它的值在 sender 构造时就被复制/移动一次，之后只读
如果要延迟求值又不想写 coroutine，用 unifex::lazy_transform 包一层 unifex::just，比裸写 task 更轻量

MSVC 默认不开启协程，即使你用了 /std:c++20，也得加 /await 才能编译 co_await 表达式 —— 否则报错 error C7555: use of 'co_await' requires /await。

Clang 和 GCC 相对友好，但 GCC 12+ 仍需 -fcoroutines，且 libunifex 的 CMakeLists.txt 默认不设该 flag。

CMake 中务必设置 set(CMAKE_CXX_STANDARD 20) 并追加 target_compile_options(your_target PRIVATE /await)（MSVC）或 -fcoroutines（GCC/Clang）
libunifex 是 header-only，但部分工具链（如 MSVC 17.4+）对 template-heavy 协程代码有 ODR 问题，建议统一用 /permissive- 编译
别把 unifex 和 boost::asio 混用 scheduler —— unifex 的 io_scheduler 不兼容 asio 的 io_context::get_executor()，强行 cast 会导致运行时崩溃