Gary Stainburn wrote:
> On Monday 05 January 2004 2:09 pm, Dan Anderson wrote:
> > > My problem is one of destroying a block (object), making sure that I have
> > > no memory leakage.
> >
> > Out of curiosity, when you say memory leakage do you mean that the
> > memory persists after the Perl process exits, or just while it is
> > running? And have you verified this? And, is the program a daemon
> > where the memory leak will build up over time? (i.e. if the program
> > runs for 10 minutes you may just want to bite the bullet and let the
> > memory leak -- if it gets cleaned up when the process exits)
>
> By memory leak, I meant a redundant object being kept in memory, i.e. refcount
> for the object still being >0 after calling the delete method.
>
> The program, while initially being an academic project for me to learn OOP,
> will eventually be interactive, potentially running for long periods and I
> didn't want it to keep grabbing more memory.
>
> The problem, like the project is really pretty academic.
One key for general durability is to start by limiting the numer of direct
references to any object or its member. For instance, once a Trainset is created,
you would want to access inidividual Tracks only through the Trainset methods, and
let it find and interact with the appropriate track. One strategy would be to
return the index of any track created, and have accessor function take an index
argument, rather than handing out direct treferences to the object. By being
stingy with direct references to contained objects, you can be assured that when
the object is removed from the list or hash within the container, it will die.
If you can be assured of that, then you can free a whole set of objects just by
assigning the container structure to a new empty hash or array:
$self->{'tracks'} = [];
Think "One-way path of reference".
Joseph
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>
