On Nov 28, 2009, at 7:50 PM, Guillaume Yziquel wrote: > Whit Armstrong a écrit : >> I've had success w/ using a reference counting paradigm in which the outside >> memory manager calls UNPROTECT_PTR(R_object_); in its destructor. >> So, in my case (using c++ ) if objects are allocated on the heap, which >> allocate R objects as their backend storage, I don't have to worry about out >> of order UNPROTECT calls b/c UNPROTECT_PTR will just put the objects that >> c++ destroys on the gc list. >> If you are using c as the glue for all your ocaml bindings, they you may >> want to have a look at this: >> http://github.com/armstrtw/rabstraction >> Or the in progress re-write here: http://github.com/armstrtw/RObjects >> -Whit > > Thanks a lot for these pointers. > > UNPROTECT_PTR seems quite interesting. As I understand it, it avoids caring > about protecting and unprotecting in the order the stacks would expect. This > is quite interesting, since I'd like to keep OCaml's GC to do housekeeping, > and not rely on referencing counting. >
FWIW what I think you should be really looking at is R_PreserveObject/R_ReleaseObject. I would suggest looking at the many other R embeddings in other languages that already exist since I don't think you approach is very viable (but I think I expressed that already before). Cheers, Simon > I'm using C as the glue, but I want it to be as thin as possible. I will > probably not do reference counting in C, for instance. Nevertheless, there's > obviously good ideas in rabstraction/RObjects that I'll adapt. > > Thanks a lot. > > -- > Guillaume Yziquel > http://yziquel.homelinux.org/ > > ______________________________________________ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
