> However, it's not generally an issue, because you shouldn't normally be keeping references around for stuff that isn't used anymore. The garbage collector is smart enough to deal with circular references and the like, so the biggest cases where you'd normally need weak references aren't actually a problem. You're trying to do something fairly abnormal here.
>

Thanks Jonathon, with some effort I hope to wriggle out of the situation.

Regards
- Cherry

On Sat, 12 Feb 2011 12:02:14 -0500, Jonathan M Davis <jmdavisProg@gmx.com> wrote:

> On Saturday 12 February 2011 08:45:03 d coder wrote:
>> > If you know roughly what to do and want to take a stab at producing a
>> > viable patch to fix the problem, then feel free. If it's solid, it may
>> > get in. I don't know. It doesn't hurt to try though (as long as you're
>> > prepared for the fact that it may not be accepted).
>>
>> Thanks for letting me know of the licensing issues. I do not think I
>> have the expertize required to fix this myself. So I hang my shoes
>> here and wait for somebody else to get stuck in a similar situation.
>
> It is a known issue, and it should probably be fixed at some point, but I don't
> think that it's a high priority. So, there's a decent chance that it will be
> dealt with, but I have no idea when.
>
> However, it's not generally an issue, because you shouldn't normally be keeping
> references around for stuff that isn't used anymore. The garbage collector is
> smart enough to deal with circular references and the like, so the biggest cases
> where you'd normally need weak references aren't actually a problem. You're
> trying to do something fairly abnormal here.

It's not a simple issue.  The GC currently is too coarse with it's pointer/no-pointer determination.

This would require a weak-ref to use double-dereferencing, and allocate a pointer on the heap, a performance disaster.

For example, if weak-ref is just a simple size_t, cast to a pointer when used, then this is still not a weak ref:

struct S
{
   int *x;
   weakref!int y;
}

because the whole struct is marked as containing pointers.  Same goes for anything allocated on the stack or TLS.  I had to deal with this in one of my most recent changes to the array append, since I needed to make the LRU cache weak-ref.

I think in order for efficient generalized weak-ref to work properly, we need precise scanning first.

-Steve

12.02.2011 18:44, d coder пишет:
>> Also tango (for D 1.0) implements it.
>> Link:
>> http://www.dsource.org/projects/tango/docs/current/tango.core.WeakRef.html
>>
>> Might be worth a look if you are going to implement it for D 2.0.
>>
> I looked at the D1 implementation. It depends on GC methods
> weakPointerCreate and weakPointerDestroy. These functions are
> implemented in D1 GC as extern C functions.
>
> It seems most of this code should be directly portable to D2, it would
> certainly require changes in the DMD2 source code. I have never worked
> at that level and have used D2 only for past couple of months. While I
> can give that a blind try,  it would be useful only if it gets
> excepted in DMD2.
>
> What do you guys suggest?
>
I remember reading a discussion about weak references some time ago. You *could* implement them using functions rt_attachDisposeEvent and rt_detachDisposeEvent, which are extern(C) and declared in object.d (actually, object_.d of dmd's druntime source), and AFAIR Tango uses something similar.

Normally, a (hypothetical) WeakRef would nullify the non-GC-scanned reference in a dispose handler. But there is an issue with this, as dispose handlers are run *after* the GC resumes all threads, which means that it is still possible that a WeakRef implementation would supply the client code a presumably valid reference just before some thread deletes/clears it - a straight way to AV/segfault. Of course, this is no problem for single-threaded applications, but then again, weak references are not that useful in such apps as their usefulness manifests almost entirely in concurrent code.

On 02/14/2011 03:34 PM, Stanislav Blinov wrote:
> 12.02.2011 18:44, d coder пишет:
>>> Also tango (for D 1.0) implements it.
>>> Link:
>>> http://www.dsource.org/projects/tango/docs/current/tango.core.WeakRef.html
>>>
>>> Might be worth a look if you are going to implement it for D 2.0.
>>>
>> I looked at the D1 implementation. It depends on GC methods
>> weakPointerCreate and weakPointerDestroy. These functions are
>> implemented in D1 GC as extern C functions.
>>
>> It seems most of this code should be directly portable to D2, it would
>> certainly require changes in the DMD2 source code. I have never worked
>> at that level and have used D2 only for past couple of months. While I
>> can give that a blind try, it would be useful only if it gets
>> excepted in DMD2.
>>
>> What do you guys suggest?
>>
> I remember reading a discussion about weak references some time ago. You
> *could* implement them using functions rt_attachDisposeEvent and
> rt_detachDisposeEvent, which are extern(C) and declared in object.d (actually,
> object_.d of dmd's druntime source), and AFAIR Tango uses something similar.
>
> Normally, a (hypothetical) WeakRef would nullify the non-GC-scanned reference
> in a dispose handler. But there is an issue with this, as dispose handlers are
> run *after* the GC resumes all threads, which means that it is still possible
> that a WeakRef implementation would supply the client code a presumably valid
> reference just before some thread deletes/clears it - a straight way to
> AV/segfault. Of course, this is no problem for single-threaded applications,
> but then again, weak references are not that useful in such apps as their
> usefulness manifests almost entirely in concurrent code.

People interested in weakref implementation may have a look at Lua. Because it's in plain standard C99 and lightweight. (but the code is not very beautiful imo and has very few comments)

Denis
-- 
_________________
vita es estrany
spir.wikidot.com