我在这个函数的外面加了互斥锁的，进入SendMessageInternal()之前。

回头我把代码扒出来弄个最小demo

之前用async_pipe操作匿名管道时，有个同事反馈退出时会卡住，我还没重现（现在经过你的指点，知道原因应该是没加work guard，导致执行run(）的那线程没活儿干退出了，而进程退出时会给对端发送一条退出消息通知对端退出，发的这条消息没人执行了，卡在wait event上了），就改成命名管道了。
进程收到退出信号，最终会调用io_context.stop()通知退出。

下面改之前的这句，确实需要加一个work_guard，防止run()没活儿干时就自动退出了


     m_thread = new std::thread([&]() { m_io->run(); });

改之后的那个放在SendMessageInternal()里的run()，就是需要它干完活儿就退出，所以不加work guard。

所以最开始的这个问题就清楚了：

执行m_io->run()的这个线程退出了，那么其他线程搞的aysnc_wait、async_write之类的异步请求根本就没线程会去给它们执行了，那当然也就不会完成了。

结帖散花，谢谢大家。后续还是要好好看看asio的文档的。

【 在 ziqin 的大作中提到: 】
: 感觉你贴出来的代码坑不少。ipc我直接用shared memory多，named pipe我不太有经验。这个函数会不会被并行调用？kernel层面对named pipe会有加锁/排队之类的操作吗？如果没有，那在user层面多少需要有个排队加锁的结构，那用asio的确没问题。
: 不过，就你这个情况来说，你现在需要一个work guard，但是相应的，你在关闭的时候需要有一个机制来reset这个work guard，不然你程序不能正常退出
:
--
修改:z16166 FROM 222.131.206.*
FROM 222.131.206.*