更换Mac自带vecLib作为R的BLAS框架后mclapply返回NULL问题求助

Hey, I’ve run into this exact issue before! When swapping R’s BLAS backend to Mac’s built-in vecLib, mclapply from the parallel package can start returning NULLs seemingly out of nowhere—even with tiny datasets like your 70×70 matrix. It’s not actually a memory problem, it’s a compatibility quirk between vecLib’s multi-threading and the way mclapply uses fork() to create child processes.

What’s Going On? #

VecLib uses its own multi-threading optimizations, but when you fork child processes (which mclapply does), the thread state from the parent process gets copied over. This causes conflicts in the child processes, leading them to fail silently and return NULL instead of your calculation results. The size of your matrix doesn’t matter here—even small operations can trigger this mismatch.

Quick Fixes to Try #

1. Limit VecLib to Single Thread (Recommended)

Add this line before running your parallel code to restrict vecLib from using multiple threads. This avoids the thread state conflict when forking:

Sys.setenv(VECLIB_MAXIMUM_THREADS = 1)

Then run your original code again:

library(parallel)
xx1 <- matrix(runif(2*70), ncol=2)
mcl.test <- mclapply(1:2, function(i) sum(tcrossprod(xx1[,i])), mc.cores = 2)
mcl.test

You should now get the actual sum results instead of NULLs.

2. Temporarily Switch Back to Default BLAS

If you don’t need vecLib for this specific task, you can launch R using its default BLAS backend instead. On Mac, you can do this from the terminal with:

open -a R --args --no-environ

This skips loading the vecLib configuration, so mclapply works as expected.

Why This Works #

By limiting vecLib to a single thread, you eliminate the conflicting thread state that gets copied to child processes during the fork operation. This keeps the child processes stable enough to complete their calculations properly.

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