Karl, I think you right, if you are not controlling all memory allocation, then you cannot do anything.
In the igraph package, I keep a stack that contains all allocated objects, and also their destructor. In case of an error, or an interrupt, I go over the stack and call all destructors. (I use on.exit to call back again to C and free everything.) It is not optimal, but works well, and it is very nice to be able to interrupt a long computation. igraph is written in C, I am not sure how difficult it is to make this work with C++. If anyone has a better solution, please don't hesitate to enlighten us.... Best Regards, Gabor On Wed, Sep 29, 2010 at 10:31 AM, Karl Forner <karl.for...@gmail.com> wrote: > Hi, > > Thanks for your reply, > > > There are several ways in which you can make your code respond to interrupts >> properly - which one is suitable depends on your application. Probably the >> most commonly used for interfacing foreign objects is to create an external >> pointer with a finalizer - that makes sure the object is released even if >> you pass it on to R later. For memory allocated within a call you can either >> use R's transient memory allocation (see Salloc) or use the on.exit handler >> to cleanup any objects you allocated manually and left over. >> > > Using R's transient memory allocation is not really an option when you use > some code, like a library, not developed for R. Moreover what about c++ and > the new operator ? > > One related question: if the code is interrupted, are C++ local objects > freed ? > Otherwise it is very very complex to attack all allocated objects, moreover > it depends on where happens the interruption > > Best, > > Karl > > [[alternative HTML version deleted]] > > ______________________________________________ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Gabor Csardi <gabor.csa...@unil.ch> UNIL DGM ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
