Re: Managing C library memory in XS

[dmitri]

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 */

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

[petermogensen]

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...

[dmitri]

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.

[petermogensen]

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.