Re: REVIEW: Extending and Embedding Perl
On Wed, Nov 27, 2002 at 10:36:04PM +, Mark Fowler wrote: [reference counting] Could you, or anyone else, give me a pointer to where this kind of thing is documented? Lperlguts/Reference Counts and Mortality, plus, if you're writing some XS and think that you're leaking something, you can always try Devel::LeakTrace (if the something is SVs) or valgrind (if the something is regular malloced blocks). -- Richard Clamp [EMAIL PROTECTED]
Re: REVIEW: Extending and Embedding Perl
On Wed, Nov 27, 2002 at 02:35:20PM +, Nicholas Clark wrote: Review of Extending and Embedding Perl Author: Tim Jenness and Simon Cozens ISBN: 1-930110-82-0 Publisher: Manning Reviewed by: Nicholas Clark pThis is a long review. I could have said the book is missing things that I think should be there and leave it at that. But it's trivial to say, easy to dismiss, and impossible to follow. As I'm clear in my head about the specifics of what I think is missing but relevant to the book's subject matter, I've backed things up every time with examples. This makes a much longer review, but hopefully much clearer to follow, and easier to understand why I hold my opinions. Maybe it's more of a short article than a review, but it says what I feel I need to say./p Ouch. OK, I will come clean, I did do an early technical review of some parts to this book, but I did not see the completed thing or even if any of my input was taken. Heck I even gave a quote for the cover as I thought it was a very promising book. Having read this please tell me its not there as I have never received my free copy. Graham.
Re: REVIEW: Extending and Embedding Perl
On Thu, 28 Nov 2002, Graham Barr wrote:
Heck I even gave a quote for the cover as I thought it was a very
promising book. Having read this please tell me its not there as I have
never received my free copy.
Perl's internals and XS can be like black magic. [This] is the 'spell
book' you need to protect and guide yourself though the deepest bepths of
this subject
-- Graham Barr, Author of the libnet package
Back of book. Also quotes from Charles Bailey, Alasdair Allan, Abhijit
Menon-Sen and Norman Gray.
Mark.
--
s'' Mark Fowler London.pm Bath.pm
http://www.twoshortplanks.com/ [EMAIL PROTECTED]
';use Term'Cap;$t=Tgetent Term'Cap{};print$t-Tputs(cl);for$w(split/ +/
){for(0..30){$|=print$t-Tgoto(cm,$_,$y). $w;select$k,$k,$k,.03}$y+=2}
Re: REVIEW: Extending and Embedding Perl
On Wed, Nov 27, 2002 at 02:35:20PM +, Nicholas Clark wrote: Review of Extending and Embedding Perl [snippety-snip] I have posted this on the web site, at: http://london.pm.org/reviews/extending-and-embedding-perl.html -- David Cantrell | Benevolent Dictator | http://www.cantrell.org.uk/david There is no sigmonster
Re: REVIEW: Extending and Embedding Perl
On Thu, Nov 28, 2002 at 11:45:13AM +, Richard Clamp wrote: On Wed, Nov 27, 2002 at 10:36:04PM +, Mark Fowler wrote: [reference counting] Could you, or anyone else, give me a pointer to where this kind of thing is documented? Lperlguts/Reference Counts and Mortality, plus, if you're writing some XS and think that you're leaking something, you can always try Devel::LeakTrace (if the something is SVs) or valgrind (if the something is regular malloced blocks). I don't really understand this stuff, but piecing together what I know and a re-skim of the perl docs and source, I *think* that the summary is 0: things (SV, AV, HV, (etc?)) are refcounted - when the refcount hits 0 the thing is freed. (which effectively means that their memory gets marked for re-use, so you may not always see symptoms if you're prematurely freeing things. it's got all the potential problems of C if you call free() and then carry on accessing that memory) but you need to return things from your code; and the things are pointers that you, not your caller, owns, and so you are responsible for cleaning them up. (like wanting to return a pointer to malloc()ed space from a C function). Except that they need cleaning up some point after your code has returned. 1: mortal describes a system for flagging a value for a deferred cleanup. If you tell perl to make something mortal, all it does is record on a TODO list that the thing (SV, AV, HV, etc) should have its reference count decreased by 1 at some later time. The later time corresponds to end of statement, ie C; in your perl script, or when C code runs the macro FREETMPS; (defined in scope.h, calls Perl_free_tmps in scope.c) Not all temporaries are freed; the stack of TODOs can have markers placed on it to nest scopes, so processing is only for things mortalized since the last marker was placed (using the ENTER; macro) mortal doesn't mean automatically freeing something at scope exit; all it does is decrease the reference count by 1. Things get freed (as a side effect) if this decrease drops their reference count to zero. One implication of this is that you can mark something as mortal more than once - this just means it will get 1 future reference count decrease per time you marked it. 2: aggregates such as references, AVs and HVs own a reference count on each SV that they contain. So when their reference count drops to 0, they relinquish ownership of all their contents, by decreasing each item's reference count by one [someone check this, please:] 3: so this means if you're returning a reference to an array or hash from your XS code, you only need to mark the top level reference as mortal; when that things reference count drops to zero, everything it owns is dropped by one. (I believe that this means the example on page 366 of Advanced Perl Programming is wrong - it makes everything it pushes into an array mortal) 4: If you still own a pointer to something, because it's static and meant to persist between calls to your routine, then you don't mortalise it. But you need to clean it up at some point. This is equivalent to returning a pointer to something you malloc()ed, but your C code retains ownership because at some future point you will free() it. 5: I believe that all the creation routines (newAV, newHV, the new SV routines) return you something with a refcount of 1. ie you have to do something with that reference, ie hold on to it and decrease it at your cleanup; give it away to someone else (somebody else's problem); or mark it mortal. All the add it to something routines (store in HV or AV) don't increase the refcount. They are assuming that you are giving them the reference. If they fail (you did check the return code, didn't you?) it's still your problem. [Perl_av_push() etc don't check] The sole exception to this is newRV, which is now an alias to the more descriptive newRV_inc, which creates a new SV holding a reference (ie that SV has a reference count of 1) plus increments the reference count of the thing you passed it. (being helpful, making an assumption) use newRV_inc() or newRV_noinc() to make your intent clear. Nicholas Clark
Re: REVIEW: Extending and Embedding Perl
At 28/11/2002 15:15 [], Mark Fowler wrote: On Thu, 28 Nov 2002, Graham Barr wrote: Heck I even gave a quote for the cover as I thought it was a very promising book. Having read this please tell me its not there as I have never received my free copy. Perl's internals and XS can be like black magic. [This] is the 'spell book' you need to protect and guide yourself though the deepest bepths of this subject -- Graham Barr, Author of the libnet package Back of book. Also quotes from Charles Bailey, Alasdair Allan, Abhijit ^^^ Menon-Sen and Norman Gray. ^ I don't know any of the other names, but that's Crab from #perl on rhizomatic... - ask if he got a book? /rataxis -- S. Joel Bernstein :: joel at fysh dot org :: t: 020 8458 2323 Nobody is going to claim that Perl 6's OO is bolted on. Well, except maybe for certain Slashdotters who don't know the difference between rational discussion and cheerleading... -- Larry Wall
Re: REVIEW: Extending and Embedding Perl
On Thu, 28 Nov 2002, Nicholas Clark wrote:
On Thu, Nov 28, 2002 at 11:45:13AM +, Richard Clamp wrote:
[someone check this, please:]
3: so this means if you're returning a reference to an array or hash from
your XS code, you only need to mark the top level reference as mortal; when
that things reference count drops to zero, everything it owns is dropped
by one. (I believe that this means the example on page 366 of Advanced
Perl Programming is wrong - it makes everything it pushes into an array
mortal)
IANAL, but doesn't making it mortal mean that it does not have a reference
for you, as it were, i.e. it will be freed at the next FREETMPS, which
is correct, since if you're pushing it into an array, you don't want a
reference to it. Presumably (IANAL again) the push operation will add a
reference, so it now has 1, which is correct.
S.
--
Shevek
I am the Borg.
sub AUTOLOAD{my$i=$AUTOLOAD;my$x=shift;$i=~s/^.*://;print$x\n;eval
qq{*$AUTOLOAD=sub{my\$x=shift;return unless \$x%$i;{$x}(\$x);};};}
foreach my $i (3..65535) { {'2'}($i); }
Re: REVIEW: Extending and Embedding Perl
On Thu, Nov 28, 2002 at 04:30:41PM +, Shevek wrote: On Thu, 28 Nov 2002, Nicholas Clark wrote: On Thu, Nov 28, 2002 at 11:45:13AM +, Richard Clamp wrote: [someone check this, please:] 3: so this means if you're returning a reference to an array or hash from your XS code, you only need to mark the top level reference as mortal; when that things reference count drops to zero, everything it owns is dropped by one. (I believe that this means the example on page 366 of Advanced Perl Programming is wrong - it makes everything it pushes into an array mortal) IANAL, but doesn't making it mortal mean that it does not have a reference for you, as it were, i.e. it will be freed at the next FREETMPS, which is correct, since if you're pushing it into an array, you don't want a reference to it. Presumably (IANAL again) the push operation will add a reference, so it now has 1, which is correct. What's L in this case? I can however say that your presumptions are wrong. When you add things to an AV by pushing it nothing ups up the refcount of them for you. av_push is implemented in terms of av_store, which has the following note in perlapi. av_store Stores an SV in an array. The array index is specified as key. The return value will be NULL if the operation failed or if the value did not need to be actually stored within the array (as in the case of tied arrays). Otherwise it can be dereferenced to get the original SV*. Note that the caller is responsible for suitably incrementing the reference count of val before the call, and decrementing it if the function returned NULL. The last sentence is the kicker. I guess that maybe you're thinking of returning things on the stack, whereby you want to mortalise them, then your caller will up the refcount when it takes the copies of the values[1] if it assigns the values to something. So that my_sub(); # the mortalised SVs die @foo = my_sub(); # they live on within @foo; [1] Unsurprisingly for perl it actually cheats and takes the entire SV if it sees that it's mortal and about to disappear rather than copying the structure about. Yet another Cunning Optimisation. -- Richard Clamp [EMAIL PROTECTED]
Re: REVIEW: Extending and Embedding Perl
On Thu, Nov 28, 2002 at 03:56:50PM +, S. Joel Bernstein wrote: At 28/11/2002 15:15 [], Mark Fowler wrote: Back of book. Also quotes from Charles Bailey, Alasdair Allan, Abhijit ^^^ Menon-Sen and Norman Gray. ^ I don't know any of the other names, but that's Crab from #perl on rhizomatic... - ask if he got a book? Charles Bailey is a VMS type, who was the pumpking for a little while back in the low 5s. -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: REVIEW: Extending and Embedding Perl
On Wed, 27 Nov 2002, Nicholas Clark wrote:
pPerl tracks which memory is in use by reference counting is structures
such as scalarsThere should be a whole section on how to do it - who owns the
reference
of items on the argument stack, which API routines increase the reference
count for you on the assumption that this will save you another call, which
API routines hook the pointer you gave them into another structure without
changing the reference count, and in effect take a reference from you.
As someone who recently had a go at XS programming, and who has read the
book, I have to agree with this one. I'm totatlly confused. HELP!
Could you, or anyone else, give me a pointer to where this kind of thing
is documented?
Mark.
--
s'' Mark Fowler London.pm Bath.pm
http://www.twoshortplanks.com/ [EMAIL PROTECTED]
';use Term'Cap;$t=Tgetent Term'Cap{};print$t-Tputs(cl);for$w(split/ +/
){for(0..30){$|=print$t-Tgoto(cm,$_,$y). $w;select$k,$k,$k,.03}$y+=2}
