in reply to Re^2: Managing C library memory in XS
in thread Managing C library memory in XS

Ok. You didn't mention there was deep nesting.

Somewhat less "hacky" than relying on the NV slot to not get overwritten by Perl, could you you live with an extra layer of indirection? That is, each time you get an unfree-able pointer, allocate a control structure to point to the unfree-able structure. This control structure would also have a field to hold the pointer you were going to put in the NV slot (plus any other fields you might need).

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

    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.
    1. Make the objects plain C pointers and keep the reference in the NV slot
    2. Make the objects an extra C indirection struct and keep the reference in that
    3. 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?

      Still no guarantee what Perl might do to those slots. I would hesitate to rely being left alone, especially in future versions of Perl.

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