From tom@@@k@liber@ @ending from gm@il@com  Thu Aug  9 21:11:59 2018
From: tom@@@k@liber@ @ending from gm@il@com (Tomas Kalibera)
Date: Thu, 9 Aug 2018 21:11:59 +0200
Subject: [Rd] 
 SIGSEGV in R_RunWeakRefFinalizer, object allocated with Rcpp
In-Reply-To: <23404.36580.740017.811392@rob.eddelbuettel.com>
References: <CALEXWq2E+-k=Oka1YZAzGzYU1bLmcC3ptUUrv8RUMUrpcviK-g@mail.gmail.com>
 <a03f65c7-3e0e-7857-0e1e-a809e1051b56@gmail.com>
 <23404.36580.740017.811392@rob.eddelbuettel.com>
Message-ID: <7227ca03-4239-670c-486c-29a6bfcfd18e@gmail.com>



On 9.8.2018 20:58, 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?
>
> 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.
Well if you wanted to support unloading - and I am not at all asking for 
that - you could keep R objects (weak references, external pointers) 
with C finalizers in some list and then unconditionally run or clear the 
finalizers in your R_unload, something like Luke does in his example 
package.

https://github.com/ltierney/Rpkg-simplemmap/blob/master/src/simplemmap.c

Best
Tomas
>
> | 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
>



[Rd] SIGSEGV in R_RunWeakRefFinalizer, object allocated with Rcpp
Tomas Kalibera