16.10.2013 3:20, Sean Kelly пишет:
> On Tuesday, 15 October 2013 at 22:09:17 UTC, Robert wrote:
>>
>> The problem is that destructors and thus the registered hooks for the
>> dispose events are called when threads are already resumed. If this
>> wasn't the case there would actually be no problems.
>
> Gotcha.  Looking at the code... I think you'll get this to work, but
> manipulating such user-mode weak references seems really expensive.  Why
> not work on a DIP to get them built in?  For example, one option might
> be to have the GC perform certain types of finalization while the world
> is stopped.  This would have to be limited to very rudimentary stuff,
> and the easiest way to guarantee that would be to have everything live
> in Druntime.

What about this:
https://github.com/D-Programming-Language/druntime/pull/639

-- 
Денис В. Шеломовский
Denis V. Shelomovskij

On Wednesday, 16 October 2013 at 10:02:28 UTC, Denis Shelomovskij wrote:
> 16.10.2013 3:20, Sean Kelly пишет:
>Looking at the code... I think you'll get this to work, but
>> manipulating such user-mode weak references seems really expensive.  Why not work on a DIP to get them built in?  For example, one option might be to have the GC perform certain types of finalization while the world is stopped.  This would have to be limited to very rudimentary stuff, and the easiest way to guarantee that would be to have everything live in Druntime.
>
> But someone have to do it. And I can only see it will save one of two GC lock/unlock pairs.

If the GC calls "block was disposed" callbacks when the world is stopped, it's possible that a WeakRef implementation wouldn't need any synchronization at all beyond whatever is necessary to prevent the compiler from optimizing anything away.  I haven't thought too hard about this though, so perhaps there's something I've missed.

On 10/16/2013 12:45 AM, Walter Bright wrote:
> http://d.puremagic.com/issues/show_bug.cgi?id=4151 does not contain the
> info in your post starting this thread, nor does it contain any link to
> this thread.
Yeah, more cross references please.
I personally dislike the DIP proliferation for anything but big changes.

On 10/13/2013 09:47 AM, Denis Shelomovskij wrote:
>
>        * Alex's one from MCI:
>
> https://github.com/lycus/mci/blob/f9165c287f92e4ef70674828fbadb33ee3967547/src/mci/core/weak.d
>

I remember talking about this with Alex.
He wanted to add some functions to the GC and this is what I came up with based on the current implementation.
It uses the synchronized GC.addrOf to check whether the loaded pointer is still valid. Still looks correctly synchronized to me.
https://gist.github.com/dawgfoto/2852438

In fact the load!(msync.acq) could be made load!(msync.raw) too.

17.10.2013 12:09, Martin Nowak пишет:
> On 10/13/2013 09:47 AM, Denis Shelomovskij wrote:
>>
>>        * Alex's one from MCI:
>>
>> https://github.com/lycus/mci/blob/f9165c287f92e4ef70674828fbadb33ee3967547/src/mci/core/weak.d
>>
>>
>
> I remember talking about this with Alex.
> He wanted to add some functions to the GC and this is what I came up
> with based on the current implementation.
> It uses the synchronized GC.addrOf to check whether the loaded pointer
> is still valid. Still looks correctly synchronized to me.
> https://gist.github.com/dawgfoto/2852438
>
> In fact the load!(msync.acq) could be made load!(msync.raw) too.

The only thing we need from `GC.addrOf` here is a "GC barrier" i.e. `lock`/`unlock` pair so runtime changes are necessary for performance.

-- 
Денис В. Шеломовский
Denis V. Shelomovskij

On Thursday, 17 October 2013 at 08:09:24 UTC, Martin Nowak wrote:
> On 10/13/2013 09:47 AM, Denis Shelomovskij wrote:
>>
>>       * Alex's one from MCI:
>>
>> https://github.com/lycus/mci/blob/f9165c287f92e4ef70674828fbadb33ee3967547/src/mci/core/weak.d
>>
>
> I remember talking about this with Alex.
> He wanted to add some functions to the GC and this is what I came up with based on the current implementation.
> It uses the synchronized GC.addrOf to check whether the loaded pointer is still valid.

I'm afraid this is insufficient.  If a same-sized block is allocated before the dispose event is triggered, the WeakRef could end up pointing to something else.  It's a rare case (in the current GC, a finalizer would have to do the allocation), but possible.  This is what I referred to as the ABA problem the other day.  Not strictly accurate, but the effect is similar.