[Rd] Is there a way to disable / warn about forking?

[Thomas Friedrichsmeier]

Dear R developers,

with the inclusion of the package "parallel" in the upcoming release of R, 
users and package developers are likely to make increasing usage of 
parallelization features. In part, these features rely on forking the R 
process. As ?mcfork points out, fork()ing in a GUI process is typically a bad 
idea. In RKWard, we "only" seem to have problems with signals arriving in the 
wrong threads, and occasional failure to collect the results from child 
processes. I haven't entirely given up the hope to fix this, eventually, but in 
consequence, parallelization based on forking is not currently usable inside 
an RKWard session.

I am somewhat worried that, as library(parallel) gains acceptance, 
unsuspecting users will increasingly start to run into forking related 
problems in RKWard and other environments. Therefore, I wish:
- The warning from ?mcfork about potential complications should also be 
visible on the documentation pages for the higher level functions 
mcparallel(), mclapply(), but also makeForkCluster().
- It would be nice to have a way to tell library(parallel) that forking is a 
bad idea in the current session, so that
  - mcfork() could stop with an informative error message, or at least produce 
a warning; mclapply() could fall back to mc.cores=1 with a warning.
  - third party packages which wish to use parallelization could check whether 
it is safe to use forking, or whether another mechanism should be used.

I am aware that options(mc.cores=1) will effectively disable forking in 
mclapply(). However, this would make it look like (local) parallelization is 
not worth while at all, while actually, parallelization with 
makePSOCKCluster() works just fine. So, I'm looking for a way to selectively 
disable the use of forking.

Thanks!
Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <https://stat.ethz.ch/pipermail/r-devel/attachments/20111004/f74cf399/attachment.bin>