Re^4: Managing C library memory in XS

Yeah ... That's the same solution as Corion suggested above. Just not as an extra indirection in the Perl layer, but at the C layer.

So now there's 3 solutions. All of them keeping a reference to the "owning" C object.

Make the objects plain C pointers and keep the reference in the NV slot
Make the objects an extra C indirection struct and keep the reference in that
Make the objects ordinary Perl blessed hashrefs and keep a reference in there to the "parent" perl object ... when will then not have it's DESTROY called before the child is gone.

I think all of them will work, but I still wonder what Perl actually guarantees about dualvalue SVs. Since its practicaly encouraged by Scarlar::Util, I would have expected such a statement in perlapi or perlguts.

To put it further into perspective. Here's Devel::Peek description of the T_PTROBJ typemap SV.. As it clearly shows, the PV and NV slots are empty (as standard). But what happens if you use them?

Comment on Re^4: Managing C library memory in XS

Replies are listed 'Best First'.
Re^5: Managing C library memory in XS by RonW (Parson) on May 06, 2014 at 16:32 UTC
Still no guarantee what Perl might do to those slots. I would hesitate to rely being left alone, especially in future versions of Perl.	[reply]
Re^6: Managing C library memory in XS by petermogensen (Sexton) on May 06, 2014 at 19:21 UTC
Yeah... reading perlguts illustrated the amount of change in internals is scary wrt. such hacks. For now, I've chosen the coward way and just deep copy everything going out of the XS layer. I'm not sure if that will give me any trouble later, but now I'll try it...	[reply]