On Thu, 9 Aug 2018, Dirk Eddelbuettel wrote:
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?
We say it because it is true. Rcpp registers C finalizers and running them after unloading 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 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 is done in C for R, with some additional hand-holding which circumvents a number of common errors. | but in either case I would not use dyn.unload() in the first | place. This problem may be just one of many. I think I'd second that. I never had much unloading packages or dynamic libraries and tend to "just say no". Both short-lived processes (ie via 'r') as well as long sessions (ie R via ESS, running for weeks) work for my workflows. Dirk
-- Luke Tierney Ralph E. Wareham Professor of Mathematical Sciences University of Iowa Phone: 319-335-3386 Department of Statistics and Fax: 319-335-3017 Actuarial Science 241 Schaeffer Hall email: luke-tier...@uiowa.edu Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
