>>>>> "MSC" == Michael Scott Cuthbert <[EMAIL PROTECTED]> writes:
MSC> [EMAIL PROTECTED] [ Jan 31 ]:
>>
>> have you thought about weak references? if you maintain a key reference
>> (or a few) as regular and make the rest weak, it will be much easier for
>> to detect when something has gone out of scope. another trick is to use
>> a second level reference above the circular structure which only has one
>> copy. when it gets destroyed it can explicitly break the circles below
>> it and also close down stuff. there is a name for this paradigm but i
>> forget it. another way which i use is to explicitly close down stuff and
>> not rely on destroy. then you get exact control over shutdown time and
>> change the worries of perl to you! :)
MSC> Our biggest concern is the, from code we've inherited (from CPAN,
MSC> from other sites) and from code we've written, the circular
MSC> references are being created. Much of the code has worked "fine"
MSC> for years--that is to say, the circular references were quickly
MSC> destroyed by perl's garbage collector at the end of the script.
MSC> But more and more we're creating mod_perl web interfaces to
MSC> already existing code which has circular references, so they
MSC> suddenly become much more of a problem.
you are mistaking end of process cleanup with reference counting
cleanup. when the process ends perl will cleanup everything regardless
of ref counts and if it doesn't the process will still exit and all
handles and sockets will be closed by the OS. and you (or your
colleague?) never mentioned modperl before which is a totally different
animal. apache doesn't usually exit so it will never have the end of
process cleanup. just another reason i think modperl is a crock. it
isn't perl anymore.
MSC> Particularly when the code was not written in house, a circular refs
MSC> debugger function would be much quicker than rewriting a module from
MSC> scratch.
but most modules will not do circular refs on their own. as i said i bet
is it callback stuff which is the most common form of that and that is
totally under your control if you use weak refs for them.
MSC> We're well aware of weak references, we need the debugger though to
MSC> figure out exactly where the circular ref is being created so that we
MSC> can apply the weakening code. But consider these two examples:
MSC> a) $foo = Foo->new('parent' => weaken($self));
MSC> package Foo;
MSC> sub new {
MSC> ...
MSC> $self->{parent} = $args{parent};
MSC> }
MSC> b) $foo = Foo->new('parent' => $self);
MSC> package Foo;
MSC> sub new {
MSC> ...
MSC> $self->{parent} = $args{parent};
MSC> weaken($self->{parent});
MSC> }
MSC> in (a) the onus is on the calling application to weaken the parent
MSC> reference. in (b) it's on the module. Which is correct? Actually,
MSC> it doesn't matter what any of us thinks is correct. It only takes one
MSC> programmer thinking (b) is correct calling a module written by someone
MSC> who thinks (a) is correct to cause problems. (the other way around
MSC> causes no problems, since it's fine to weaken something twice).
if you are using other modules which you can't control you have to
weaken the refs yourself. so why not weaken them always when passing
into a module? as you said, it won't hurt and it is a good practice. it
should be easy enough to find those cases by searching for $self and
where it is passed to module code.
the analysis of the refs may not tell you all that you want to know such
as where in the code the circle happened. it only can tell you where in
the symbol table ae refs. also if you use lexicals (as you should) it
won't help there at all.
again, i have offered my help for you if you want it. i do code review
for many people and clients (just ask this list about code at meetings
:) and i could help you solve this.
uri
--
Uri Guttman ------ [EMAIL PROTECTED] -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
_______________________________________________
Boston-pm mailing list
Boston-pm@mail.pm.org
http://mail.pm.org/mailman/listinfo/boston-pm
