[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [sc-dev] Finalizers



No, you have some other problem. GCWrite does not create a reference 
and calling toGrey is not a fix.
When you call NewFinalizer is the collect argument true? If so make it
false. You don't want to collect when you have an unreferenced object.

InstallFinalizer calls NewFinalizer with the collect argument as false, and when I was calling it directly I also using false, so this isn't the issue.

I've created a simple example to demonstrate the problem. In the example FinalizerTest is a class with alloc and init methods. These methods call the same primitive function (_FinalizerTest_Call), which instantiates a new FinalizerTest class and sets up a finalizer object in it's first slot. It also prints (to stderr) the address of the object it is returning and the method (init or alloc) that it was called from. The finalizer call back just prints the address of the object being finalized. What you can see is that when running a loop like:

500.do({
g = FinalizerTest.alloc.init;
g = nil;
})

It will (occasionally, usually towards the end) finalize the object returned by FinalizerTest.alloc before calling init. You will see output like this:

Selector: alloc, Returning: 0x157850f0
Finalizing: 0x15786f50
...
Finalizing: 0x157850f0
Selector: init, Returning: 0x15786f50

When I initially started working on the example, however, I couldn't make it finalize between messages. What I found was that if I gave the primitive an unused argument with something that needed to be collected AND before calling the primitive called a nop function like {}.value, it would then finalize inappropriately. Very weird, and very inconsistent as well.

I've attached the primitive C source (FinalizerTestPrimitives.cpp), the SC class definition (FinalizerTest.sc), and the test loop above (FinalizerTest.rtf). I'm running on an Intel Mac (10.4) if you suspect this is an arch. problem. Also, I found a post from 2005 from someone else having difficulties with finalizers (http://www.create.ucsb.edu/pipermail/sc-dev/2005-October/009262.html), which increases the likelihood of this being a bug. I've spent way too much time on this, so I'd appreciate you looking at it!

Thanks,
Ryan

Attachment: FinalizerTestPrimitives.cpp
Description: Binary data

Attachment: FinalizerTest.sc
Description: Binary data

{\rtf1\mac\ansicpg10000\cocoartf824\cocoasubrtf420
{\fonttbl\f0\fnil\fcharset77 Monaco;}
{\colortbl;\red255\green255\blue255;}
\pard\tx560\tx1120\tx1680\tx2240\tx2800\tx3360\tx3920\tx4480\tx5040\tx5600\tx6160\tx6720\ql\qnatural\pardirnatural

\f0\fs18 \cf0 500.do(\{\
	g = FinalizerTest.alloc.init;\
	g = nil;\
\})}