search for: r_unload_

On 9 August 2018 at 20:37, Tomas Kalibera wrote: | So to answer your original question, this could probably be handled in | Rcpp, Hm. Why do you say that / what did you have in mind? Recall that we do not alter SEXPs or introduce additional additional reference counters -- because we do not think that altering the basic R API for such calls would be a wise strategy. So we do more or less what

...ld be better for Rcpp > (and everyone else) to explicitly discourage unloading as it is > unreliable on many levels. > > What Rcpp could do to avoid segfaulting is to keep a weak list of all > objects to which it attaches C finalizers and arrange for those to be > cleaned up in an R_unload_<dllname> routine. Not clear it is worth the > trouble. At the R level we could provide more support for this since > we already have a weak list of objects with finalizers, but again not > clear it is worth the trouble. > > Best, > > luke > > > Recall that we do...

...will segfault. For now it would be better for Rcpp (and everyone else) to explicitly discourage unloading as it is unreliable on many levels. What Rcpp could do to avoid segfaulting is to keep a weak list of all objects to which it attaches C finalizers and arrange for those to be cleaned up in an R_unload_<dllname> routine. Not clear it is worth the trouble. At the R level we could provide more support for this since we already have a weak list of objects with finalizers, but again not clear it is worth the trouble. Best, luke > Recall that we do not alter SEXPs or introduce additional ad...

...t;> (and everyone else) to explicitly discourage unloading as it is >> unreliable on many levels. >> >> What Rcpp could do to avoid segfaulting is to keep a weak list of all >> objects to which it attaches C finalizers and arrange for those to be >> cleaned up in an R_unload_<dllname> routine. Not clear it is worth the >> trouble. At the R level we could provide more support for this since >> we already have a weak list of objects with finalizers, but again not >> clear it is worth the trouble. >> >> Best, >> >> luke >&...

...d to R_ext/BLAS.h and included in R_ext/Applic.h and R_ext/Linpack.h for backward compatibility. o R will automatically call initialization and unload routines, if present, in shared libraries/DLLs during dyn.load() and dyn.unload() calls. The routines are named R_init_<dll name> and R_unload_<dll name>, respectively. See the Writing R Extensions Manual for more information. o Routines exported directly from the R executable for use with .C(), .Call(), .Fortran() and .External() are now accessed via the registration mechanism (optionally) used by packages. The ROUTINES fi...

...d to R_ext/BLAS.h and included in R_ext/Applic.h and R_ext/Linpack.h for backward compatibility. o R will automatically call initialization and unload routines, if present, in shared libraries/DLLs during dyn.load() and dyn.unload() calls. The routines are named R_init_<dll name> and R_unload_<dll name>, respectively. See the Writing R Extensions Manual for more information. o Routines exported directly from the R executable for use with .C(), .Call(), .Fortran() and .External() are now accessed via the registration mechanism (optionally) used by packages. The ROUTINES fi...