On 5 February 2011 at 08:52, Douglas Bates wrote:
| As Dirk and Romain know I have been struggling to debug a memory
| protection problem that I encounter in code based on Rcpp Modules. As
| with all memory protection problems, it is very difficult to track
| down and I have kind-of run out of options right now.
Yes, sorry, I wish your code wouldn't run into this. My much lighter use of
Modules has help up so far.
| I plan, for the time being, to use code that acts like the
| module-based code without going through the modules. I plan to create
| the object in C++ and pass back an external pointer that will be used
| to locate the object for later method calls. Perhaps it is lack of
| imagination but I haven't thought of a way to construct an object and
| make it persistent until I decide to release the pointer. The best
| way I have been able to derive is to put the C++ object on a global
| stack but that approach screams "error-prone".
|
| My question may be somewhat vaguely stated. What I am trying to avoid
| is creating an object in C++ and returning an Rcpp::XPtr then, on
| return to R, having the C++ object go out of scope so the external
| pointer's target is gone. Somehow I need to hold on to the C++ object
| until the XPtr object is garbage collected.
|
| Suggestions welcome.
One heavy-handed approach would be old-school stack based, ie either a global
array or a static one as in
static myClass pool[ N ];
and you then hand out elements of this array. That avoids garbage collection
alltogether. There are loads of C++ implementations of memory pools out there
as there are
performance sensitive applications that want to avoid allocation, garbage
collection, ... at the C++ layer too. Google finds lots of pahes for 'C++
memory pool' and e.g. the good folks at Boost have something too
http://www.boost.org/doc/libs/1_45_0/libs/pool/doc/index.html
but I should add that never used this Boost library.
A somewhat lighter approach could still work with XPtr. When I used objects
via external pointers them, I think I just bound allocation to their ctor and
dtor. Should that not be enough to protect the object from R's garbage
collection? Mind you, I generally created few and large objects which
persisted (eg using bigmemory); what you do probably involves orders of
magnitude more objects which is probably why the bug rears its ugly head.
Dirk
--
Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com
_______________________________________________
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
