future包说明中提及mcapply已知不稳定的具体含义是什么？

若部分包或外部库在原生代码中实现多线程并行处理，同时又使用forked（又称“multicore”）并行处理时，并行化方案已知不稳定。请注意该问题不仅在使用plan(multicore)时存在，使用parallel包的mclapply()等场景下同样存在。

此处的不稳定同时包含运行崩溃、结果不可靠两类问题，两种风险都可能出现：

• 进程崩溃类问题：fork机制创建子进程时仅会复制父进程的用户态内存，不会复制原生代码（C/C++/Fortran）层面的线程状态、互斥锁、文件句柄等资源。如果父进程已经加载了自带多线程的原生库（如OpenBLAS、MKL、多线程版本的data.table、深度学习框架底层库），fork出的子进程调用这些库时，会因为资源状态不一致触发段错误、死锁，直接导致R任务崩溃退出，无返回结果。
• 结果异常类问题：部分原生库不会触发显性崩溃，但fork后的子进程中内部计算状态被破坏，会出现计算结果错误、精度缺失、返回值结构异常等问题，这类问题通常不会有报错提示，属于静默故障，排查成本极高。

• 使用fork类并行（plan(multicore)/mclapply()）前，先将所有原生库的多线程开关关闭，设置线程数为1，例如配置环境变量OMP_NUM_THREADS=1、调用data.table::setDTthreads(1)等。
• 无法确认依赖库是否有多线程逻辑时，优先使用psock类并行而非fork类并行，避免冲突。

内容的提问来源于stack exchange，提问作者Eric T Simandle