Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl Monk, Perl Meditation
 
PerlMonks  

Re^2: When to (and not to) use sv_2mortal()

by patcat88 (Deacon)
on Oct 29, 2011 at 15:06 UTC ( #934612=note: print w/ replies, xml ) Need Help??


in reply to Re: When to (and not to) use sv_2mortal()
in thread When to (and not to) use sv_2mortal()

You should (only) use sv_2mortal() on scalars that are placed on the stack.

I disagree. Some people, including CPAN authors, use sv_2mortal() and sv_grow() as a direct replacement for alloca in XS. I prefer the real alloca.

# define alloca( size )    sv_grow( sv_newmortal(), size )


Comment on Re^2: When to (and not to) use sv_2mortal()
Download Code
Re^3: When to (and not to) use sv_2mortal()
by BrowserUk (Pope) on Oct 30, 2011 at 01:10 UTC

    My assertion is meant to signify that you should only use sv_2mortal() on SVs returned to the user via the stack, and not on SVs returned to the user embedded within other data structures (hashes & arrays), references to which are returned to the user via the stack.

    In that context, I believe the advice is correct.

    I never heard or read of this 'substitute for alloca' use to which you allude, but I would be very interested if you could expand a little or point to some documentation regarding that?


    With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
    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.
      cpan/Win32API-File/buffers.h#l244 in perl.git

      I'm talking about the above. Original author even says its intended to be a replacement for alloca. Also, someone correct me if I'm wrong, but I've read rumors in Perl's source that SVs can "steal" the strings/PVs of other SVs leaving the source SV undefined. I've seen it on defelem 'y' magic SVs that come in on the Perl Stack. The mess in sv_setsv sv.c#l4227 in perl.git does, sometimes, maybe, steal the PV from source to destination SV. I guess some programmers might be intentionally taking advantage of the fact that mortalized SVs can give up their PVs to a destination SV. For example, in an XSUB with C style data return in parameter scalars, if the C func fails, dont touch the value of the parameter Perl Stack SV, let the mortal SV disappear in the return, or in the croak. The author of Win32API::File obviously isn't doing that since the SV * is tossed leaving only the char */PV around. Remember (not to you BrowserUk), croaks in XS and dies in Perl are implemented using a Perl Stack unwinder (will call DESTROY if objs), and a C Stack unwinder (setjmp/longjmp). If you malloc a block (or new anything in C++), callback into Perl without eval protection and the CV dies, you just leaked memory. Using the sv_grow/mortal macro above would give you a croak safe C++ smart pointer in XS, using alloca would too. The magic system can also cause you to run Perl unintentionally in XS. Not sure if the magic system sets up an eval catch or not if the C func or Perl sub croaks/dies in the magic setter/getter. Not sure what else in the XS/C perl api can croak other than magic SVs and callbacks into Perl. The definition of mortal should be "the caller shall delete the SV if the caller shall not need it when the callee returns to the caller". The warnings about needing to return to Perl or ENTER/LEAVE blocks in perlguts or whereever it is still stands, AKA, never make mortal SVs in a non hard coded iteration loop (while(i<10) is good, while(i<runtimes), while(!exit), while(job = oldjob->Next) is very bad). You'll run out of memory/ "C stack overflow" (but its not a C stack overflow, its heap memory you ran out of). Can you think of any other uses of mortal system? :-)

        patcat88 Thank you for taking me at my word and taking the time to post this. I am still, and possibly always destined to be, nothing more than a neophyte XS dabbler; a needs-must source diver; and a reluctant visitor to those worlds. There are many reasons for this, but primary among them is the lack of good feedback on the subject.

        I do not yet understand all of what you've said, so I will need to re-visit it till I do. To that end, I am re-posting your content below having applied a little formatting, as I found the combination of its density and my tired eyes too hard to read, and I don't want to have to reformat it every time I revisit it.

        I'm talking about the above. Original author even says its intended to be a replacement for alloca.

        Also, someone correct me if I'm wrong, but I've read rumors in Perl's source that SVs can "steal" the strings/PVs of other SVs leaving the source SV undefined.

        I've seen it on defelem 'y' magic SVs that come in on the Perl Stack. The mess in sv_setsv sv.c#l4227 in perl.git does, sometimes, maybe, steal the PV from source to destination SV.

        I guess some programmers might be intentionally taking advantage of the fact that mortalized SVs can give up their PVs to a destination SV.

        For example, in an XSUB with C style data return in parameter scalars, if the C func fails, dont touch the value of the parameter Perl Stack SV, let the mortal SV disappear in the return, or in the croak.

        The author of Win32API::File obviously isn't doing that since the SV * is tossed leaving only the char */PV around.

        Remember (not to you BrowserUk), croaks in XS and dies in Perl are implemented using a Perl Stack unwinder (will call DESTROY if objs), and a C Stack unwinder (setjmp/longjmp).

        If you malloc a block (or new anything in C++), callback into Perl without eval protection and the CV dies, you just leaked memory.

        Using the sv_grow/mortal macro above would give you a croak safe C++ smart pointer in XS, using alloca would too.

        The magic system can also cause you to run Perl unintentionally in XS. Not sure if the magic system sets up an eval catch or not if the C func or Perl sub croaks/dies in the magic setter/getter.

        Not sure what else in the XS/C perl api can croak other than magic SVs and callbacks into Perl.

        The definition of mortal should be "the caller shall delete the SV if the caller shall not need it when the callee returns to the caller".

        The warnings about needing to return to Perl or ENTER/LEAVE blocks in perlguts or whereever it is still stands,

        AKA, never make mortal SVs in a non hard coded iteration loop (while(i<10) is good, while(i<runtimes), while(!exit), while(job = oldjob->Next) is very bad).

        You'll run out of memory/ "C stack overflow" (but its not a C stack overflow, its heap memory you ran out of).

        Can you think of any other uses of mortal system? :-)


        With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
        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.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://934612]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others lurking in the Monastery: (7)
As of 2014-09-20 11:14 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    How do you remember the number of days in each month?











    Results (158 votes), past polls