I put your code into a file tmp.R and eliminated the need for a package by
compiling this to a shared object
R CMD SHLIB tmp.c
I'm then able to use a simple script 'tmp.R'
dyn.load("/tmp/tmp.so")
fullocate <- function(int_mat)
.Call("C_fullocate", int_mat)
int_mat <- rbind(c(5L, 6
For the record: I filed a bug report here
https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17807
and this is a more polished minimal example
library(parallel)
nslaves <- 2
cl <- makeCluster(nslaves)
X <- matrix(c(1,0,1),1,3)
res <- parCapply(cl,X,FUN=function(x){
Hi,
I am curious about whether there exist thread-safe functions in
`Rinternals.h`. I know that R is single-threaded designed, but for the
simple and straightforward functions like `DATAPTR` and `INTEGER_GET_REGION`,
are these functions safe to call in a multi-thread environment?
Best,
Jiefei
You should assume that NO functions or macros in the R API are
thread-safe. If some happen to be now, on some platforms, they are
not guaranteed to be in the future. Even if you use a global lock you
need to keep in mind that any function in the R API can signal an
error and execute a longjmp, so
Jiefei,
Beyond the general response that Luke gave, to be a bit more specific to
what you said, DATAPTR and INTEGER_GET_REGION involve ALTREP method
execution (for ALTREP objects, obviously) so even they are not as simple
and straightforward as they were a couple years ago. They should not (any
lo
