Re: Live_Objects behavior depends on garbage collection timing

[prev] [thread] [next] [Date index for 2004/07/09]

--=-shuWtrX49wY7OTPMLDQ6
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

On Thu, 2004-07-08 at 19:16, Siamak Pazirandeh wrote:
> Not so. There is another consideration, which is the timing of the
> garbage collection. This can cause objects that have no reference to
> them to still remain in the %Class::DBI::Live_Objects hash for some
> undefined amount of time, until garbage collection sets the weakly
> referenced objects to undef. In the meanwhile, any retrieves of that
> object will grab from the cache or DB, unpredictably.

No offense, but how much do you know about the implementation of the
garbage collector?  My impression has always been that there is no pause
between the reference count on an object dropping to zero and that
object being destroyed.  In fact, people write code that depends on
this, where they assume that the DESTROY() method on their object will
get called as soon as it goes out of scope.

I tried to reproduce your results with a variation of the code you
posted, but could not.  It always showed that the value inside the
%Live_Objects dump was undef.  I'm attaching my script to this message.

One thing that would be helpful is if you could change your
dump_object_index() method to something like this:

sub dump_object_index {
    use Devel::Peek;
    my @defined = grep { defined } values %Live_Objects;
    print Dump(\@defined);
}

If you see anything in there with a REFCNT of 0, that means that
Scalar::Util::weaken doesn't actually work the way we need it to, and we
have to yank the "single instance" feature out of Class::DBI.  If you
see things with REFCNT > 0, that means you still have references to them
somewhere in your program.  If that's the case, and you can't find them,
post some code and maybe we can help.

> It is understandable that a caching system based on weak refs will
> have this kind of behavior.

(It's not a caching system!)

It's not understandable for a caching system based on reference counting
to behave the way you're describing.  If it did, we would have
out-of-scope objects behaving like legitimate in-scope data all over the
place in lots of people's programs, and it would wreak havoc.  If I
can't count on $cd being undefined when it's references have dropped to
zero, that would be a pretty serious problem with Perl.

> For now, I am going to do as others on the list seem to be doing,
> which is to override _init and turn off this caching behavior
> alltogther.

Much simpler: set $Class::DBI::Weaken_Is_Available = 0 after loading
Class::DBI.

I'm sorry to hear that you are having trouble with the single instance
feature, and I hope you will reconsider trying to find the problem
rather than just turning it off.

- Perrin

--=-shuWtrX49wY7OTPMLDQ6
Content-Disposition: attachment; filename=live_test.pl
Content-Type: application/x-perl; name=live_test.pl
Content-Transfer-Encoding: 7bit

#!/usr/bin/perl

use strict;
use warnings;

use Data::Dumper;
use Scalar::Util qw(weaken);

my %Live_Objects;

do {
    my $lexical = 7;
    weaken($Live_Objects{'key'} = \$lexical);
};

print Dumper(\%Live_Objects);
--=-shuWtrX49wY7OTPMLDQ6--