From: MLM Veraart (veraart++at++fel.tno.nl)
Date: 06/24/2005 08:57:53
Try to add a couple of pfFrame() calls in the loop that uses pfDelete().
To my knowledge pfDelete() is kind of a delayed delete that is
controlled by the number of frames past after the call.
This is to ensure that CULL, DRAW, ISECT, COMPUTE can still use the
object.
If you still get a different pointer every call it might be that the allocation sceme
for shared memory prefers a free region that surely can contain the object.
Or that it does not join adjacent free regions that might lead to the well known
memory fragmentation that Performer shared memory suffers from.
Mario Veraart
NeBuR I wrote:
> I fear this will surely have been discussed in the past, but I haven't
> found it in the archive. I apologize if I'm falling back to an answered
> question.
>
> Well, my question is about deletion of performer objects. Initially, all
> classes derived from pfMemory should their objects to be deleted with
> pfDelete(), instead of standard c++ operator delete. But some tests I've
> done incite me to ask myself if memory is really freed with pfDelete().
>
> I've tried three simple pieces of code:
>
> // Test #1: new/delete of C++ built-in type.
> while (true)
> {
> float * f = new float;
> cout << "new float: 0x" << f << endl;
> delete f;
> }
>
> The first test always prints out the same pointer value, which is a
> clear evidence of memory being reserved and freed. If memory wouldn't be
> freed, operator new should return a different pointer value each iteration.
>
> // Test #2: new/pfDelete of pfGroup.
> pfInit();
> pfConfig();
> while (true)
> {
> pfGroup * g = new pfGroup;
> cout << "new pfGroup: 0x" << g << endl;
> pfDelete(g);
> }
> pfExit();
>
> The second test prints out a different pointer value each iteration.
> That is what takes me to think there's something wrong here with
> pfDelete().
>
> // Test #3: new/delete of pfGroup.
> pfInit();
> pfConfig();
> while (true)
> {
> pfGroup * g = new pfGroup;
> cout << "new pfGroup: 0x" << g << endl;
> delete g;
> }
> pfExit();
>
> The third and last test works as expected, as in the first one, with
> operator new always returning the same pointer value.
>
> Now, my questions are: do this three tests prove the wrong behaviour of
> pfDelete(), or perhaps I'm forgetting something? Is there a corruption
> risk over shared memory pool when using operator delete with pfMemory
> derived objects, beyond ignoring the reference counting mechanism?
>
> Thank you in advance.
-- ------------------------------------------------------------------------------ The disclaimer that applies to e-mail from TNO can be found on: http://www.tno.nl/disclaimer/email.html ------------------------------------------------------------------------------
This archive was generated by hypermail 2b29 : Fri Jun 24 2005 - 08:57:58 PDT