in reply to [XS] How to detect the TEMP flag

This is a case of the blind leading the blind, so watch my step. Which I guess translates to "Listen carefully, because I shall say this only once--and probably wrong".

The effect you are describing seems to be associated with the mysteries and magic of TARGs. Those temporary stack items that are created at compile time and reused by different subs/ops and even recursive re-invocations of the same sub. They are related to the well-known optimisation that means that some sub variables don't get cleaned up when they return, but rather persist to be reused next time.

There is some scant mention of them in the sections: "Putting a C value on Perl stack", "Scratchpads" & "Scratchpads and recursion" of Perlguts, but it is less than clear. At least to me when I encountered this a couple of years ago.

I found that if you ensure that subroutine return values are explicitly set sv_2mortal(), many of the traps "went away", but I fear that I may have been creating SVs that would never get cleaned up?

Hopefully, someone who knows what they are talking about will set the record straight, but maybe this mention will trigger understanding in your brain. I've personally got half a dozen ideas for modules that need XS but on whihc I can make no progress for my failure to understand this mechanism (amongst others:().

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

Replies are listed 'Best First'.
Re^2: [XS] How to detect the TEMP flag
by syphilis (Archbishop) on Nov 20, 2008 at 12:23 UTC
    I found that if you ensure that subroutine return values are explicitly set sv_2mortal(), many of the traps "went away", but I fear that I may have been creating SVs that would never get cleaned up?

    I think that's the main difference. I'm creating persistent objects that ought to be cleaned up - but only when they go out of scope. I don't think I can make use of 'sv_2mortal' for this particular exercise. (I could be wrong about that ... I'll have to give it some more thought.)

    Hopefully, my reply to ikegami's reply makes things a little clearer. (My original post suffers from having been written 10 minutes too early. I hate it when that happens.)
    I do know that if I don't bless the object into any package, then everything works fine. The only problems then are that:
    1) we'll get memory leaks if:
        a) the user doesn't manually call the clean-up function;
        b) the Rmpc_realref return value is not assigned to a variable;
    2) the Rmpc_realref return value can't be used with the overloaded Math::MPFR operators.

    Cheers,
    Rob
[reply]

In Section Seekers of Perl Wisdom