Re^3: Managing C library memory in XS

Aaah - I didn't understand that connection. The easy approach here would be to let Perl do all your reference counting.

Make the person a hash entry in your (Perl) Person class, and have ->get_person also store the (Perl) Record object in the Person hash. This is most easy done on the Perl side.

This way, as long as the Person is alive, the Record object belonging to the Person is also alive. The person data structure will then also stay valid through the Record object.

Comment on Re^3: Managing C library memory in XS Select or Download Code

Replies are listed 'Best First'.
Re^4: Managing C library memory in XS by petermogensen (Sexton) on May 05, 2014 at 13:51 UTC
Yes... I that seems like an workable solution which ensures that any memory owning object is not freed before all references to contained objects are gone. It's a bit hard to maintain code wise though... isn't it? I mean... every perl method using an XS method must know which objects to keep a reference to. ... and that requires knowledge about how the XS code is implemented It basically does the same as I suggested with the NV field: Increment the refcnt on the record object and store a back-reference to it so it can be decremented with the person object has DETROY called. Only difference is doing that on the Perl side. I don't think doing it on the XS side like I proposed with abusing the NV field is difficult. Actually it's a lot less code. The question is how large a red light it lights up :-)	[reply]
Re^5: Managing C library memory in XS by Corion (Patriarch) on May 05, 2014 at 13:56 UTC
Better the code knows which memory belongs to whom than if the programmer has to remember that.	[reply]