Weak References

[Steven Schveighoffer]

"Bill Baxter" wrote
> On Thu, Aug 7, 2008 at 11:38 PM, Steven Schveighoffer
> <schveiguy at yahoo.com> wrote:
>> "Bill Baxter" wrote
>>> On Thu, Aug 7, 2008 at 8:12 AM, Jason House wrote:
>>>
>>> One possible gotcha that just crossed my mind:  I think the current GC
>>> allocates chunks in an all or nothing manner -- hasPointers is just a
>>> single bit.  So could it be that the fact that all Objects have a
>>> vtable pointer mean that everything in an Object is always treated as
>>> having pointers?
>>
>> At least on Tango, this is not the case:
>>
>> import tango.core.Memory;
>>
>> class X
>> {
>>    int x;
>> }
>>
>> class Y
>> {
>>    int *y;
>> }
>>
>> void main()
>> {
>>    auto n = new X;
>>    assert(GC.getAttr(cast(void*)n) & GC.BlkAttr.NO_SCAN);
>>    auto m = new Y;
>>    assert(!(GC.getAttr(cast(void*)m) & GC.BlkAttr.NO_SCAN));
>> }
>
> Hmm, yeh I also went looking for the previous discussion on this topic
> and found there that someone had already checked that the GC flag on
> the WeakRef class was getting set properly.
>
> The only other potential problem I can see is the manipulation of the
> member variable that goes on in the destructor of the WeakRef.  It
> makes the assumption that if the referred object has been collected
> then the notification function will have been called, and thus the
> pointer-as-size_t variable will be null.  But that code is very
> similar to what std.signals does in its destructor.  So if that's the
> source of the bug then it's probably a bug that's in std.signal too.

I don't think that's possible.  In order for this to cause a problem, the GC 
would have to collect the memory from the referred object before calling 
your hook, or else that it doesn't call your hook at all.  Neither of these 
seem likely.

Looking through your code with thread-oriented eyes, and assuming that any 
thread can cause a collect cycle at any time, it seems that it is impossible 
for a race to occur.

-Steve