After refreshing my R installation and the packages, this simple example of BiocParallel::bplapply doesn't work properly. It looks like it starts, but never finishes.
Thanks for taking a look into it!
Vlad
> library(BiocParallel) > fun <- function(v) { + message("working") ## 10 tasks + sqrt(v) + } > bplapply(1:10, fun) # it does not finish (at least in a minute or so) > sessionInfo() R version 3.3.1 (2016-06-21) Platform: x86_64-apple-darwin13.4.0 (64-bit) Running under: OS X 10.10.4 (Yosemite) locale: [1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8 attached base packages: [1] stats graphics grDevices utils datasets methods base other attached packages: [1] BiocParallel_1.6.6 loaded via a namespace (and not attached): [1] parallel_3.3.1 tools_3.3.1 >
It hits a snag at this line in bplapply
BPPARAM <- bpstart(BPPARAM, length(X))
Within bpstart the issue is at
bpbackend(x) <- .bpmakeForkCluster(nnodes, bptimeout(x), getOption("ports", NA_integer_))
A likely candidate is that ports on the Mac are not accessible; I'm not familiar enough with how things work, but I think the overall strategy would be to identify open ports and use these via
options(ports=123)
.Not sure if this is relevant but this is what I get (regardless of the port). Although may be this is what is supposed to be since there is no process communicating to the 11709 port. Anyway,
BiocParallel:::.bpmakeForkCluster
is not cooperating with me today.What is odd it starts with MulticoreParam(), that is FORK type, but later switches to SOCK type. I thought SOCK is for Windows, but not POSIX systems.
The 'SOCK' class of the return value is a red herring here. A simple fork isn't rich enough to support the BiocParallel behavior, which requires communication between the forked and master process. Sockets are used for that communication.
If I intercept the execution and rename the host from
"WE25743"
(the name of my machine) to"localhost"
, then.bpmakeForkCluster
proceeds just fine. Hope that helps.