New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[PATCH] improve docs about mortal in perlguts #13996
Comments
From @bulk88Created by @bulk88Unsmoked. See attached patch. Perl Info
|
From @bulk880001-improve-docs-about-mortal-in-perlguts.patchFrom 543c0e688ee3c5a452b9203e04eee8a0f448ecfa Mon Sep 17 00:00:00 2001
From: Daniel Dragan <bulk88@hotmail.com>
Date: Tue, 22 Jul 2014 11:33:06 -0400
Subject: [PATCH] improve docs about mortal in perlguts
---
pod/perlguts.pod | 16 +++++++++++++---
1 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/pod/perlguts.pod b/pod/perlguts.pod
index 105e817..b8d2d77 100644
--- a/pod/perlguts.pod
+++ b/pod/perlguts.pod
@@ -787,7 +787,11 @@ manipulated with the following macros:
int SvREFCNT(SV* sv);
SV* SvREFCNT_inc(SV* sv);
+ SV* SvREFCNT_inc_NN(SV* sv);
+ void SvREFCNT_inc_void(SV* sv);
+ /* see perlapi for other variants */
void SvREFCNT_dec(SV* sv);
+ void SvREFCNT_dec_NN(SV* sv);
However, there is one other function which manipulates the reference
count of its argument. The C<newRV_inc> function, you will recall,
@@ -822,13 +826,16 @@ See L<perlcall> and L<perlxs> for more details on these macros.
"Mortalization" then is at its simplest a deferred C<SvREFCNT_dec>.
However, if you mortalize a variable twice, the reference count will
-later be decremented twice.
+later be decremented twice. Mortal can be thought of as attached a SV to
+the current scope of the Perl stack (but not putting the SV on the Perl stack),
+and the SV will be freeded if nothing else wants it, when the scope is left.
+Mortal is similar to a C++ smart pointer.
"Mortal" SVs are mainly used for SVs that are placed on perl's stack.
For example an SV which is created just to pass a number to a called sub
is made mortal to have it cleaned up automatically when it's popped off
the stack. Similarly, results returned by XSUBs (which are pushed on the
-stack) are often made mortal.
+stack) are often made mortal; the few exceptions are listed further down.
To create a mortal variable, use the functions:
@@ -858,7 +865,10 @@ as deferred C<SvREFCNT_dec> should help to minimize such problems.
For example if you are passing an SV which you I<know> has a high enough REFCNT
to survive its use on the stack you need not do any mortalization.
If you are not sure then doing an C<SvREFCNT_inc> and C<sv_2mortal>, or
-making a C<sv_mortalcopy> is safer.
+making a C<sv_mortalcopy> is safer. A real example would be getting a SV * from
+C<get_sv>. In that case, the SV is owned by the package namespace. If you just
+mortal the package SV, you will probably free the SV in the glob, causing a perl
+panic or crash.
The mortal routines are not just for SVs; AVs and HVs can be
made mortal by passing their address (type-casted to C<SV*>) to the
--
1.7.9.msysgit.0
|
From @tonycozOn Tue Jul 22 08:35:48 2014, bulk88 wrote:
"Mortalization" then is at its simplest a deferred C<SvREFCNT_dec>. Should probably be "Mortalization can be thought of attaching an SV to ..."[1] +the current scope of the Perl stack (but not putting the SV on the Perl stack), There's a enough differences that this comparison might be confusing. Anyone else? Tony [1] I pronounce SV as ess-vee, so "an" instead of "a", perlguts uses "a SV" once, "an SV" several times |
The RT System itself - Status changed from 'new' to 'open' |
From @TuxTony Cook via RT schreef op 2014-07-23 01:37:
freeded?
|
From @iabynOn Tue, Jul 22, 2014 at 08:35:48AM -0700, bulk88 wrote:
I'm not particularly keen on this phrasing and am not sure what it's -- |
From @bulk88On Tue Jul 22 16:37:37 2014, tonyc wrote:
-freeded fixed, -- |
From @bulk880001-improve-docs-about-mortal-in-perlguts.patchFrom 761d128f341c67af9d00072fdfc77d9d19f63a9c Mon Sep 17 00:00:00 2001
From: Daniel Dragan <bulk88@hotmail.com>
Date: Tue, 28 Apr 2015 13:10:10 -0400
Subject: [PATCH] improve docs about mortal in perlguts
---
pod/perlguts.pod | 19 ++++++++++++++++---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/pod/perlguts.pod b/pod/perlguts.pod
index 9761bad..be72d9d 100644
--- a/pod/perlguts.pod
+++ b/pod/perlguts.pod
@@ -805,7 +805,11 @@ manipulated with the following macros:
int SvREFCNT(SV* sv);
SV* SvREFCNT_inc(SV* sv);
+ SV* SvREFCNT_inc_NN(SV* sv);
+ void SvREFCNT_inc_void(SV* sv);
+ /* see perlapi for other variants */
void SvREFCNT_dec(SV* sv);
+ void SvREFCNT_dec_NN(SV* sv);
However, there is one other function which manipulates the reference
count of its argument. The C<newRV_inc> function, you will recall,
@@ -840,13 +844,18 @@ See L<perlcall> and L<perlxs> for more details on these macros.
"Mortalization" then is at its simplest a deferred C<SvREFCNT_dec>.
However, if you mortalize a variable twice, the reference count will
-later be decremented twice.
+later be decremented twice. Mortalization can be thought of attaching an SV to
+the current scope, or current executing statement of Perl code, and upon the
+change to the next Perl language scope (C<}>), or next Perl language statement
+(C<;>), or XS synthesis of those 2 Perl langauge concepts, the SV will be
+freed if nothing else wanted to retain the SV. Mortal is similar to a C++
+smart pointer.
"Mortal" SVs are mainly used for SVs that are placed on perl's stack.
For example an SV which is created just to pass a number to a called sub
is made mortal to have it cleaned up automatically when it's popped off
the stack. Similarly, results returned by XSUBs (which are pushed on the
-stack) are often made mortal.
+stack) are often made mortal; the few exceptions are listed further down.
To create a mortal variable, use the functions:
@@ -876,7 +885,11 @@ as deferred C<SvREFCNT_dec> should help to minimize such problems.
For example if you are passing an SV which you I<know> has a high enough REFCNT
to survive its use on the stack you need not do any mortalization.
If you are not sure then doing an C<SvREFCNT_inc> and C<sv_2mortal>, or
-making a C<sv_mortalcopy> is safer.
+making a C<sv_mortalcopy> is safer. A real example would be getting an SV *
+from C<get_sv>. In that case, the SV is owned by the package namespace. If
+you just C<sv_2mortal> the package SV, you will probably free the SV in the
+glob, causing a perl panic or crash. If you C<SvREFCNT_inc> and then
+C<sv_2mortal> the package SV, that is safe, but inefficient.
The mortal routines are not just for SVs; AVs and HVs can be
made mortal by passing their address (type-casted to C<SV*>) to the
--
1.8.0.msysgit.0
|
From @tonycozOn Tue Apr 28 12:35:10 2015, bulk88 wrote: It might be better to just say that FREETMPS is called in those places. Tony |
From @bulk88On Wed May 27 00:03:09 2015, tonyc wrote:
I think saying only "calls FREETMPS" is unhelpful. FREETMPS is another macro. Documenting any 2 macros as being the opposites of each other, doesn't say what they are, or when to use them. I want to connect the mortal concept of XS code to something in PP code, that a XS newbie will understand, since all XS programmers come from PP programmers (I hope). -- |
From @bulk88On Sat Aug 08 22:24:55 2015, bulk88 wrote:
Bump. -- |
From @tonycozOn Tue Apr 28 12:35:10 2015, bulk88 wrote:
+the current scope, or current executing statement of Perl code, and upon the s/langauge/language/ "or XS synthesis of those 2 Perl langauge concepts" This is kind of vague to me. @@ -876,7 +885,11 @@ as deferred C<SvREFCNT_dec> should help to minimize such problems. I tend to think of this in terms of "ownership" of the reference - did I create the reference*? If so I can mortalize it. I don't own a reference from get_sv() and no longer own a reference I've stored in a HV, AV or GV. Expressing that clearly and concisely might be hard though. Again, other opinions desired. Tony * in this the "reference" being an increment of the reference count of some SV, including the starting count on a new SV |
From zefram@fysh.orgI have heavily revised that doc section in commit -zefram |
@xsawyerx - Status changed from 'open' to 'resolved' |
Migrated from rt.perl.org#122368 (status was 'resolved')
Searchable as RT122368$
The text was updated successfully, but these errors were encountered: