--- Proposal ---

The proposal is to add weak reference functionality based on `unstd.memory.weakref`. It can be placed e.g. in `core.memory`.

Source code: https://bitbucket.org/denis-sh/unstandard/src/HEAD/unstd/memory/weakref.d
Documentation: http://denis-sh.bitbucket.org/unstandard/unstd.memory.weakref.html
Enhancement request: http://d.puremagic.com/issues/show_bug.cgi?id=4151

--- Reasons ---

Reasons, why we do need weak reference functionality in D (Issue 4151 [1]):

  1. It has a general use.

    I suppose no question here.


  2. It's hard to implement correctly.

    As a proof here are incorrect implementations written by experienced developers:
      * Weak reference functionality in `std.signal` implementation:

https://github.com/D-Programming-Language/phobos/blob/7134b603f8c9a2e9124247ff250c9b48ea697998/std/signals.d

      * Alex's one from MCI:

https://github.com/lycus/mci/blob/f9165c287f92e4ef70674828fbadb33ee3967547/src/mci/core/weak.d

      * Robert's one from his new `std.signals` implementation proposal:

https://github.com/phobos-x/phobosx/blob/d0cc6b45511465ef1d493b0d7226ccb990ae84e8/source/phobosx/signal.d

      * My implementation (fixed now, I hope):

https://bitbucket.org/denis-sh/unstandard/src/cb9a835a9ff5/unstd/memory/weakref.d

    Everybody can check his knowledge of concurrent programming and D GC by trying to understand what exactly every implementation does and where are race conditions. It's recommended to read implementations in the order provided here going to the next one as soon as you see why previous one is incorrect. For now the only [probably] fixed implementation is mine so one can see spoiler here:

https://bitbucket.org/denis-sh/unstandard/history-node/HEAD/unstd/memory/weakref.d
      (the first and the most fixing (spoiling you joy to understand everything yourself) commit is 6f59b33)


  3. It's hard to create a good API design for it.

    No jokes. E.g. there are two different behaviours of .NET weak references and even more in Java library.


  4. It is needed for correct signals implementation in D.

    The lack of correct signals implementation is one of [major?] disadvantages of D.
    Bug report: http://d.puremagic.com/issues/show_bug.cgi?id=9606

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

Am 13.10.2013 09:47, schrieb Denis Shelomovskij:
> --- Proposal ---
>
> The proposal is to add weak reference functionality based on
> `unstd.memory.weakref`. It can be placed e.g. in `core.memory`.
>
> Source code:
> https://bitbucket.org/denis-sh/unstandard/src/HEAD/unstd/memory/weakref.d
> Documentation:
> http://denis-sh.bitbucket.org/unstandard/unstd.memory.weakref.html
> Enhancement request: http://d.puremagic.com/issues/show_bug.cgi?id=4151
>
> --- Reasons ---
>
> Reasons, why we do need weak reference functionality in D (Issue 4151 [1]):
>
>    1. It has a general use.
>
>      I suppose no question here.
>
>
>    2. It's hard to implement correctly.
>
>      As a proof here are incorrect implementations written by
> experienced developers:
>        * Weak reference functionality in `std.signal` implementation:
>
> https://github.com/D-Programming-Language/phobos/blob/7134b603f8c9a2e9124247ff250c9b48ea697998/std/signals.d
>
>
>        * Alex's one from MCI:
>
> https://github.com/lycus/mci/blob/f9165c287f92e4ef70674828fbadb33ee3967547/src/mci/core/weak.d
>
>
>        * Robert's one from his new `std.signals` implementation proposal:
>
> https://github.com/phobos-x/phobosx/blob/d0cc6b45511465ef1d493b0d7226ccb990ae84e8/source/phobosx/signal.d
>
>
>        * My implementation (fixed now, I hope):
>
> https://bitbucket.org/denis-sh/unstandard/src/cb9a835a9ff5/unstd/memory/weakref.d
>
>
>      Everybody can check his knowledge of concurrent programming and D
> GC by trying to understand what exactly every implementation does and
> where are race conditions. It's recommended to read implementations in
> the order provided here going to the next one as soon as you see why
> previous one is incorrect. For now the only [probably] fixed
> implementation is mine so one can see spoiler here:
>
> https://bitbucket.org/denis-sh/unstandard/history-node/HEAD/unstd/memory/weakref.d
>
>        (the first and the most fixing (spoiling you joy to understand
> everything yourself) commit is 6f59b33)
>
>
>    3. It's hard to create a good API design for it.
>
>      No jokes. E.g. there are two different behaviours of .NET weak
> references and even more in Java library.
>
>
>    4. It is needed for correct signals implementation in D.
>
>      The lack of correct signals implementation is one of [major?]
> disadvantages of D.
>      Bug report: http://d.puremagic.com/issues/show_bug.cgi?id=9606
>

I like the idea of adding weak references to phobos.

Will rt_attachDisposeEvent also work with std.allocator? Or does it rely on the GC running?

Kind Regards
Benjamin Thaut

Denis, you forgot to say that it's need to download yours unstd library source too. Also there's only visualdproj to build it.

Am 13.10.2013 09:47, schrieb Denis Shelomovskij:
> --- Proposal ---
>
> The proposal is to add weak reference functionality based on
> `unstd.memory.weakref`. It can be placed e.g. in `core.memory`.
>
> Source code:
> https://bitbucket.org/denis-sh/unstandard/src/HEAD/unstd/memory/weakref.d
> Documentation:
> http://denis-sh.bitbucket.org/unstandard/unstd.memory.weakref.html
> Enhancement request: http://d.puremagic.com/issues/show_bug.cgi?id=4151

+1

Bikeshed: I'd use "lock()" instead of "@property target()" based on precedence in the form of C++'s weak_ptr, but in general that should be a very valuable (and long overdue) addition.

Just to reassure, the following race-condition doesn't exist, right? It looks like "GC.addRoot()" makes guarantees by taking the GC lock or something similar?

         time ->
thread1: GC collection |               | run finalizer |
thread2: paused        | lock weak ref |               | access object

13.10.2013 12:55, Sönke Ludwig пишет:
> Am 13.10.2013 09:47, schrieb Denis Shelomovskij:
> Just to reassure, the following race-condition doesn't exist, right? It
> looks like "GC.addRoot()" makes guarantees by taking the GC lock or
> something similar?
>
>           time ->
> thread1: GC collection |               | run finalizer |
> thread2: paused        | lock weak ref |               | access object
>

All public GC API uses same mutex. So right, no races here. )

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

13.10.2013 12:36, Benjamin Thaut пишет:
> Will rt_attachDisposeEvent also work with std.allocator? Or does it rely
> on the GC running?

What exactly do you mean? `rt_attachDisposeEvent` adds delegate to `object.__monitor.devt` array which is called from `rt_finalize2 -> _d_monitordelete -> _d_monitor_devt`.

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

>        * Robert's one from his new `std.signals` implementation proposal:
> 
> https://github.com/phobos-x/phobosx/blob/d0cc6b45511465ef1d493b0d7226ccb990ae84e8/source/phobosx/signal.d
> 

Obviously I don't see it, otherwise I would have fixed it. Maybe you could elaborate a bit on your claim? Your implementation uses an entirely different technique for hiding the reference so a direct comparison is quite hard.

Best regards,

Robert

And line 61: what exactly mean a two !! in alive property?

+1 weakref

On 10/13/13 11:07 AM, Michael wrote:
> And line 61: what exactly mean a two !! in alive property?

"Convert this to bool".

Andrei

On 10/13/2013 12:47 AM, Denis Shelomovskij wrote:
> --- Proposal ---

Please post as a DIP:

http://wiki.dlang.org/DIPs

The trouble with it as a n.g. posting is they tend to scroll off and be forgotten.