[Swig-devel] Re: handling callback objects

[Jason S. <jas...@gm...>]

Hey All,

On 1/21/06, Marcelo Matus <mm...@ac...> wrote:
> William S Fulton wrote:
>
> > I can't see any info on this in the CHANGES files. There is something
> > in Customization.html but I don't understand how it works. The docs
> > imply that %delobject will delete some memory for some parameters for
> > a function. The example has just one parameter. What if there are lots
> > of parameters? When does the memory get deleted, after the C function
> > has returned?
>
>
> lot of questions!, ie, we need to expand the Customization.html:

[snip]

 I have something that is related but not identical.

I'm wondering how one solves this in SWIG.

The C++ library has callback object registration methods - so you
create a Perl object (say a ErrorHandler), and then call a method
which registers that object in the C++ library (say
parser->setErrorHandler()). Later an even will trigger a callback
method invoked on that stored object (say ErrorHandler::fatal()).

The problem is that Perl doesn't know that the C++ library is keeping
a reference to the object so it will happily garbage collect the
object at the end of the setErrorHandler() registration method, and
when the parser callback happens the object has already been deleted,
which leads to segfault or random stuff.

I worked around the problem by keeping a hash table of registered
objects inside the perl module. Then when the parser object is
deleted, it deletes all objects that it has registered with C++.

This callback registration should be pretty common for C++ I would
think. How do others handle it? If there isn't already a way to do
this for SWIG, is it worth adding a feature?

Thanks, jas.