Re: [MacPerl] Memory problems in OO context

[Matthew Langford <langfml [at] eng [dot] auburn [dot] edu>]

On Mon, 29 Nov 1999, Ronald J Kimball wrote:

> > I undef $p (my filter object instance), checking ref $p before and after.
> > Before it is true, after it is false, which seems like Perl should then be
> > able to reclaim it.
> 
> It seems that you have not yet fully grasped the concept of circular
> references.

I think my point of confusion was the ref operator.  I was thinking it
meant "are there references to this?" and hence potentially helpful to me,
rather than "does this refer to something real?" and hence totally
worthless to me at this time.



>   $x   +->  [ 0, 1, 2, * ]
>        |_______________|
> 

Okay, maybe I can use a similar diagram to explain my situation...


   $p   +->  { Parser/Filter internals -> values,..., 
               myObject temp variables  -> values,...,
               myData -> { category1 -> { order -> some_number,
                                          value -> some_string,
                                          field1 -> { order ->  some_number,

and so on, recursively. When I've finished parsing the file, $p must go,
but I need to keep myData, since that's the whole point.  To keep memory
from vanishing, I need to delete all the Parser/Filter internals and
myObject temp variables.  I copy the ref to myData and return it, but
undef $p.  I thought this would allow $p to be reclaimed, yet myData would
persist.  Is this not happening?  Why would $p hang around? Or why is
anything other than myData persisting?

I collect all the myDatas from each file, and put them a big hash slung
around by Storable.  They aren't too big.

I've gone to the trouble of doing this
        $theInfo = \@{$p->{myData}};
        undef $p->{myData};
        return $theInfo;
thinking maybe this would allow $p to be freed.  No go.


--
MattLangford 


# ===== Want to unsubscribe from this list?
# ===== Send mail with body "unsubscribe" to macperl-request@macperl.org