如何避免基于subprocess创建的Python无关联子进程mmap通信的忙等待

当前的wait方法本质是弱化版的轮询忙等：哪怕加了10ms的sleep间隔，依然需要周期性唤醒进程、读取mmap内存校验消息是否就绪，不仅会产生无意义的CPU空转开销，消息响应延迟也被10ms的轮询周期锁死，完全达不到零忙等的要求。

所有方案的核心都是把「主动轮询内存」改成「内核态阻塞等待事件通知」：等待过程中进程会被挂起在系统内核的等待队列上，不占用任何CPU时间片，等事件到达后由内核主动唤醒进程，从根源消除空转。

1. 复用现有跨进程信号量基础，拆分互斥/通知两类信号量 #

这是改动量最小、最贴合现有代码的方案：

• 你现在的代码已经在__read_message中使用跨进程信号量__sem2做共享内存读写的临界区保护，本身已经具备跨进程同步的基础，只需要额外新增一个独立的「消息就绪」信号量即可
• 子进程完成共享内存的消息写入、清空对应标记后，触发通知信号量的release()操作
• 主进程的wait方法完全不需要保留循环校验逻辑，直接调用通知信号量的acquire(timeout=3)做内核态阻塞等待，收到唤醒后再走原有__read_message的临界区逻辑读消息、清空共享内存区域
• 原有的3秒超时逻辑可以直接通过acquire的timeout参数实现，不需要自行记录启动时间计算差值
• 优势：唤醒延迟在微秒级，没有额外的数据拷贝开销，完全复用现有mmap的高性能传输通道，等待阶段CPU占用接近0

2. 结合selectors监听管道/套接字事件，支持多源等待 #

如果后续需要同时等待多个事件（比如子进程退出、其他网络IO），可以采用这个方案：

• 主进程启动子进程时，利用subprocess自带的stdout管道，或者额外创建socketpair搭建主从进程间的通知通道
• 实际的消息内容依然存在原有的mmap共享内存中，管道只传输1个字节的「消息就绪」通知，避免大内存拷贝的性能损耗
• 主进程的wait方法直接通过selectors模块注册管道读事件，阻塞等待事件触发，收到通知后再从mmap读取实际消息内容
• 优势：可以无缝整合其他IO等待事件，不需要单独维护信号量的配对逻辑，同样原生支持超时等待

3. 复用跨进程Event同步原语，降低自研同步复杂度 #

如果不想手动管理信号量的计数和配对逻辑，可以选用这个方案：

• multiprocessing提供的Event对象底层基于跨进程共享信号量实现，主进程创建Event实例后，把它底层的跨进程句柄编号通过环境变量、命令行参数传给subprocess启动的子进程
• 子进程启动时根据句柄编号重新打开对应的Event实例，写完共享内存的消息后调用set()触发事件
• 主进程的wait方法直接调用Event的wait(timeout=3)做阻塞等待，被唤醒后正常读取消息即可
• 优势：封装度高，不需要自行处理信号量的释放、计数配对问题，同样实现零忙等，超时逻辑和原有业务规则完全对齐

• 不要继续保留任何形式的循环读mmap的逻辑，哪怕加了sleep间隔，本质还是轮询，只是降低了CPU占用率，没有彻底消除忙等
• 所有上述阻塞式同步原语都内置了超时参数，完全可以替代原有自行计算时间差的超时判断逻辑，减少冗余代码

内容的提问来源于stack exchange，提问作者void