As previously threatened, I went through and added sv_2mortal() where
necessary. This isn't as good as a real explanation of why and where to
use sv_2mortal() but it's better than nothing!
I also plugged myself as a mad scientist who uses the "Evaling C" recipe
in real code for insane, and utterly unnecessary, speedups.
-sam
PS: In case you're wondering, yes, I really did run the examples inside a
loop and verify that they leaked and that the leak goes away after the
patch. Procrastination is a powerful thing!
--- C-Cookbook.pod.orig Mon Mar 4 21:53:54 2002
+++ C-Cookbook.pod Mon Mar 4 21:52:50 2002
@@ -235,13 +235,13 @@
Inline_Stack_Vars;
Inline_Stack_Reset;
- Inline_Stack_Push(newSViv(ltime->tm_year));
- Inline_Stack_Push(newSViv(ltime->tm_mon));
- Inline_Stack_Push(newSViv(ltime->tm_mday));
- Inline_Stack_Push(newSViv(ltime->tm_hour));
- Inline_Stack_Push(newSViv(ltime->tm_min));
- Inline_Stack_Push(newSViv(ltime->tm_sec));
- Inline_Stack_Push(newSViv(ltime->tm_isdst));
+ Inline_Stack_Push(sv_2mortal(newSViv(ltime->tm_year)));
+ Inline_Stack_Push(sv_2mortal(newSViv(ltime->tm_mon)));
+ Inline_Stack_Push(sv_2mortal(newSViv(ltime->tm_mday)));
+ Inline_Stack_Push(sv_2mortal(newSViv(ltime->tm_hour)));
+ Inline_Stack_Push(sv_2mortal(newSViv(ltime->tm_min)));
+ Inline_Stack_Push(sv_2mortal(newSViv(ltime->tm_sec)));
+ Inline_Stack_Push(sv_2mortal(newSViv(ltime->tm_isdst)));
Inline_Stack_Done;
}
END_OF_C_CODE
@@ -250,6 +250,8 @@
Perl is a language where it is common to return a list of values from a subroutine
call instead of just a single value. C is not such a language. In order to accomplish
this in C we need to manipulate the Perl call stack by hand. Luckily, Inline provides
macros to make this easy.
+The calls to C<sv_2mortal> are necessary to allow Perl to properly garbage-collect
+the SVs pushed onto the stack. See L<perlguts> for more information about mortal
+variables.
+
This example calls the system C<localtime>, and returns each of the parts of the time
struct; much like the perl builtin C<localtime()>.
NOTE: The C<#include> statement is not really needed, because Inline automatically
includes the Perl headers which include almost all standard system calls.
@@ -1102,7 +1104,7 @@
void c_func_2(SV* text) {
Inline_Stack_Vars;
- Inline_Stack_Push(newSVpvf("Plus an extra line"));
+ Inline_Stack_Push(sv_2mortal(newSVpvf("Plus an extra line")));
Inline_Stack_Done;
perl_call_pv("main::perl_sub_1", 0);
Inline_Stack_Void;
@@ -1117,6 +1119,8 @@
The first time we call C<c_func_1> which calls C<c_func_2>. The second time we call
C<c_func_2> directly. C<c_func_2> calls the Perl subroutine (C<perl_sub_1>) using the
internal C<perl_call_pv> function. It has to put arguments on the stack by hand. Since
there is already one argument on the stack when we enter the function, the
C<Inline_Stack_Push> adds a second argument. C<Inline_Stack_Void> makes sure that
nothing is returned from the function.
+The call to C<sv_2mortal> is necessary to allow Perl to properly garbage-collect the
+SV pushed onto the stack. See L<perlguts> for more information about mortal
+variables.
+
=item See Also
See L<Inline::C> for more information about Stack macros.
@@ -1156,7 +1160,7 @@
The nice thing is that once a particular snippet is compiled, it remains cached so
that it doesn't need to be compiled again. I can imagine that someday a mad scientist
will dream up a self generating modeling system that would run faster and faster over
time.
-If you know such a person, have them drop me a line.
+One such mad scientist is Sam Tregar. His HTML::Template::JIT module uses Inline::C
+as a just-in-time compiler for template files.
=item See Also
