[Proposal] Weak reference implementation for D

[robert]

>
> 1. Have you read `gc.gc.fullcollect`, I mean a general function 
> structure, not every line? If not, read it or you have no idea 
> how collection performs.

I haven't, I relied on: http://dlang.org/garbage.html , but I
will now - thanks. If the information at garbage.html isn't
completely wrong I have some idea though.

>
> 2. I'm surprised you do think your implementation is correct as 
> calling code twice (`foreach(i; 0..2)`) is an obvious hack to 
> decrease a variety of undesired threads execution order (as it 
> have to execute in this order twice).

Maybe you should read the code twice ;-) In the second run I
already have a visible address to the object. I retrieve it a
second time, because exactly the GC could have kicked in right
before seeing it, but in this case my invisible address gets
reset to null so I detect this case in the second iteration
(where it can't be collected any longer). The solution might not
be perfect and there might be a better one, but in my view it
should work.

> ----- Explanation -----
>
> 1. Race condition
>   In every moment GC thread can be paused in state it already 
> marked all dead blocks and ready to collect. So before 
> `GC.addrOf` (which will have to wait for the end of the 
> collection as it uses same mutex) call it can collect your 
> object (the object can be on stack or whatever, doesn't 
> matter). Also an new object can be created occupying the same 
> memory and `GC.addrOf` will return non-null.

Exactly the reason why I retrieve it twice. This way I detect a
collection and reassignment, because my invisible address would
have been set to null. With GC.addrof I ensure that it was
already set to null before checking.

>
> 2. Incorrect assumption
>   `o = GC.addrOf(tmp.address)` is just incorrect as you assume 
> the object is placed at the base address of its memory block 
> which is not guaranteed. Yes, it may be true for now (I haven't 
> read GC sources enough to be definite here) in general case but 
> what about some e.g. tricky user defined class instance 
> sequences which user may create? Yes, never heard about it and 
> just invented it, but it doesn't make this or similar case 
> impossible. Also it's rather bad to do any needless assumption 
> about internal stuff.

That's actually a good catch, thank you. I took it from another
implementation without proper checking. Will fix it.

>
> ----- P.S. -----
>
> I have to say you have a big problem especially for a 
> programmer: you think you are competent in area you aren't and 
> it can play a trick on you later. Please don't be angry with 
> me, we all like to think so but we all have to look at 
> ourselves as critically as possible to prevent problems in 
> future.

Why would I be angry with a stranger who insults me in public? I
don't understand your concerns.

I did not write my signal implementation because of this bug, but
because of a number of other issues. I happened to stumble across
this one too, so I obviously had to fix it. If you are more
experienced in this area I am glad if you share your insights and
if you think something is wrong, I am glad to discuss it and fix
it if you are right, but just saying your implementation is
wrong, does not really help. It implies that you are obviously
right and everyone who does not see this is obviously a moron, if
someone has a bit of a problem with his ego, I don't think it is
me.