Hi,
I don't think so, because IMHO it makes no sense - you're missing the main point that R is not thread safe. There are ways to use threads from within R very cautiously (see Luke's parallelized vector math operations for R for example). There are many good methods to use threads in general (pthreads, OpenMP, GCD, ...) and you can do that as long as you don't use memory allocation in R and don't call any R functions that may do that (which is most of them ;)). Making R thread-safe is not really an issue of a threading toolkit...
Memory allocation does not necessarily make a function non-reentrant unless non-shared static variables are involved. There are a number of thread-safe malloc implementations. I admit, I have not looked at the R-internals in a long time.
Based on converting code to be thread safe when I helped port the JDK to Linux, I was amazed about how much code was already reentrant capable and therefore basically thread-safe (or could be made so with small effort - adding a few locks). In fact the original JVM (jdk 1.0) had a "green-threads" implementation that basically ended up adding wrappers to most of the memory allocation and io system calls system calls to make the whole thing work.
How much of the code itself is now reentrant safe - I noticed that some of the R-internal routines actually used reentrant code and even recursion? How hard would it be to make the internal object/memory allocation scheme thread-safe? As you noted there are many posix threads (pthreads) implmentations out there.
Is there any official effort underway to make R thread-safe? If so, are they looking for volunteers. Would making R fully thread-safe really make that much sense given you can parallelize vector/matrix operations now (as you noted) which probably provides the most bang for the buck.
Thanks, Kevin ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
