使用multiprocessing替代kthread并行运行Kaldi语音识别任务出现异常

直接将支持可终止能力的kthread实例替换为multiprocessing.Process后出现无规律随机异常，本质是多线程与多进程的运行模型存在本质差异，和任务函数是否需要传入额外参数没有直接关联，常见诱因与修复方向如下：

核心异常触发原因 #

• 设备与原生资源的并发竞争：原kthread基于线程模型运行，所有线程共享进程内的Kaldi模型全局上下文、PyAudio麦克风采集句柄；替换为多进程后，两个子进程拥有独立的内存空间，同时申请同一个16kHz单声道麦克风设备时，若没有做跨进程互斥控制，会随机触发音频流读取失败、原生库内存段错误、Kaldi模型初始化崩溃的问题——这类随机异常在macOS、Linux的严格音频设备权限管控下出现概率更高。
• 原生库的进程启动模式不兼容：Kaldi识别库、PyAudio这类带C/C++原生扩展的依赖，很多不兼容Linux默认的fork进程启动模式，跨环境运行时若没有统一进程启动配置，会随机出现进程内存访问违规的报错。
• 强终止逻辑引发的资源泄漏：原kthread的可终止能力是基于线程内部标记位实现的，替换为Process后若直接照搬原有终止逻辑、调用terminate()强杀进程，会导致子进程持有的麦克风设备锁、Kaldi模型内存没有正常释放，引发程序退出时、重复启动时的随机崩溃。

具体适配操作步骤 #

• 在程序最开头（所有依赖导入、进程创建逻辑之前）强制设置兼容原生扩展的进程启动模式，避免fork机制带来的内存拷贝异常：multiprocessing.set_start_method('spawn', force=True)
• 新增跨进程共享的麦克风设备互斥锁，每个子进程在初始化PyAudio音频流前先申请锁，拿到锁后再开启音频采集，杜绝多进程同时抢占麦克风设备的并发冲突：通过multiprocessing.Manager()创建全局共享锁实例，作为参数传入两个子进程的任务入口
• 把原来的kthread强制终止逻辑替换为优雅退出机制：用multiprocessing.Event()创建跨进程退出信号，主进程需要停止任务时将信号置位，子进程循环检测到信号后，依次关闭PyAudio音频流、释放Kaldi模型资源，再正常退出，禁止直接调用terminate()强杀进程
• 移除所有模块全局层面的Kaldi模型初始化、PyAudio实例创建逻辑，所有原生资源的初始化操作全部放到子进程的入口函数内部完成，避免spawn模式下全局资源无法同步到子进程引发的上下文找不到类报错

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