On Thu, Sep 13, 2012 at 5:05 PM, Rafael Schloming <r...@alum.mit.edu> wrote:
> On Thu, Sep 13, 2012 at 4:46 PM, Rajith Attapattu <rajit...@gmail.com>wrote:
>> On Mon, Sep 10, 2012 at 1:36 PM, Rafael Schloming <r...@alum.mit.edu>
>> > On Mon, Sep 10, 2012 at 9:26 AM, Darryl L. Pierce <dpie...@redhat.com
>> > methods on Messenger and Message objects and by tying pn_messenger_free
>> > pn_message_free into the respective destructors, we could make things a
>> > whole lot safer, e.g. avoid dangling pointers and the like that a user
>> > could use to segfault the interpreter.
>> Darryl, you could use %typemap(freearg) to ensure the respective free
>> function is called to cleanup.
>> How it gets called is also automatically handled by swig based on the
>> host language.
> Maybe I'm missing something, but I don't think %typemap(freearg) helps in
> this case. From what I understand it's used to clean up temporary memory
> allocated for the purpose of argument processing. The situation I'm talking
> about is when you allocate an object in C and return it to the interpreter,
Sorry I misunderstood. I thought it was for methods.
It appears Ruby does have support for %newobject
But it maybe simpler to use the strategy Rafi has used for the python binding.
> msg = pn_message()
> What swig returns to the interpreter here is a wrapper around a pointer. If
> that variable goes out of scope and the interpreter garbage collects it,
> then only the wrapper is freed, and the memory pointed to by the internal
> pointer is leaked.
> You can fix this by doing pn_message_free(msg) before it goes out of scope,
> however for a short time you end up with the wrapping object having an
> internal pointer that is invalid since it now points to freed memory. If
> you the try to do things you can cause the interpreter to seg fault just
> like the C runtime would seg fault if you were to try to use a pointer
> after freeing it.
> You can use %newobject and %delobject to address this, however I'm given to
> understand that support for that varies across target languages. It's
> fairly easy to work around with a destructor in the wrapper layer as I've
> done in the idiomatic python API layer.