[Rd] checking user interrupts in C(++) code

[Gábor Csárdi]

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.forner at 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 at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>



-- 
Gabor Csardi <Gabor.Csardi at unil.ch>     UNIL DGM