根本原因是Pipe缓冲区溢出且无背压机制，子进程高频send()而主线程recv()阻塞滞后，导致管道断裂；解决方案是主线程用poll()+超时非阻塞接收，子进程配合send_nowait()和状态检测，实现两端协同。
为什么multiprocessing.Pipe在高频通信时容易BrokenPipeError
根本原因不是代码写错，而是Pipe缓冲区溢出后子进程继续send()触发内核报错。尤其在PyQt绘图、音频采集等场景中，子进程按固定采样节奏（如每125ms一次）持续send()，而主线程UI处理慢或事件队列积压，导致recv()阻塞或滞后，Pipe缓冲区填满——后续send()直接抛出BrokenPipeError。
用poll() + 超时避免阻塞式recv()
把主线程里死等的recv()换成带超时的轮询，让接收节奏可控，不卡主线程：
while self.running:
if self.data_from_process.poll(0.01): # 最多等10ms
try:
data = self.data_from_process.recv()
# 处理数据并emit信号
except EOFError:
break
else:
# 没数据就继续循环，不阻塞
continue-
poll(timeout)返回True才调recv()，避免无数据时永久阻塞 - 超时设太小（如
0.001）会空转耗CPU；太大（如0.1）可能丢帧；通常0.01是平衡点 - 必须配合
try/except EOFError，因为子进程退出时管道另一端关闭，recv()会抛这个异常
子进程侧加背压控制：别只管send，要检查对方是否还活着
子进程不能无脑高频send()，得主动感知接收端状态：
- 用
pipe.send_nowait()替代send()，它在缓冲区满时立刻抛queue.Full而不是BrokenPipeError，便于捕获后降频或丢弃旧数据 - 定期调
pipe.poll(timeout=0.1)确认主线程还在读——如果连续几次都False，说明UI卡死或崩溃，应暂停发送 - Windows下Pipe更脆弱，建议在
send()前加os.write(pipe.fileno(), b'')试探（需先获取底层fd），但注意这会破坏Pipe抽象，仅作最后手段
DataLoader的num_workers设为0真能解决问题？
在PyTorch训练中遇到BrokenPipeError，很多人直接把num_workers=0，但这只是掩盖问题：
立即学习“Python免费学习笔记（深入）”；
-
num_workers=0确实绕过多进程通信，但数据加载变单线程，GPU利用率暴跌 - 真正该查的是自定义
Dataset.__getitem__里有没有不可序列化对象（如lambda、嵌套类实例）、或用了全局状态（如未加锁的random.seed()） - Linux上可尝试
spawn启动方式替代fork：torch.multiprocessing.set_start_method("spawn")，避免父进程资源被错误继承
多进程Pipe没有内置背压，靠单边控制注定失败；必须两端协同——发送端节制，接收端不阻塞，缺一不可。
