in reply to Managing C library memory in XS

And the problem is that I can't see when I get a "person" pointer I get back in DESTROY whether I'm allowed to free it.

This is the key paragraph and decision point in the code. You should wrap the real free_person() in XS function that would have the logic like this: 

    if (person_refcnt(person) == 0)
        free_person(person);
    else
        ; /* Do nothing: free_record() will free the person as well */

[download]
Then from Perl just call this wrapper and let the lower-level logic worry about it.

Replies are listed 'Best First'.
Re^2: Managing C library memory in XS
by petermogensen (Sexton) on May 05, 2014 at 12:44 UTC

    I'm not sure I follow you here ... Are you suggesting to make perl code explicitly call the wrapper (instead of relying on DESTROY) and keeping a separate (non perl) refcount for every person pointer in the module?

    That's how I read your suggestion, since the Perl refcount is always zero when DESTROY is called, right...
[reply]
      Are you suggesting to make perl code explicitly call the wrapper (instead of relying on DESTROY) and keeping a separate (non perl) refcount for every person pointer in the module?

      Call the wrapper from DESTROY.

      The library you are using knows about the references and counts, so you should be able to figure out in your XS code whether to really free an object (person, in this case). In Perl code (DESTROY), simply call your XS function, which will know what to do.

[reply]
        The library you are using knows about the references and counts

        Ahh.. No. It does not.

        There's not more to the C library interface than I described. Functions returning pointers and a documentation which tells you if you are allowed to free the returned pointer. No reference counting. It's plain C without any magic.

[reply]

In Section Seekers of Perl Wisdom