RCArray is unsafe

[Andrei Alexandrescu via Digitalmars-d]

On 3/3/15 9:40 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm at gmx.net>" wrote:
> On Tuesday, 3 March 2015 at 17:00:17 UTC, Zach the Mystic wrote:
>> On Tuesday, 3 March 2015 at 16:31:07 UTC, Andrei Alexandrescu wrote:
>>>> I was dazzed, but I'm not anymore. I wrote my concern here:
>>>>
>>>> http://forum.dlang.org/post/ylpaqhnuiczfgfpqjuww@forum.dlang.org
>>>
>>> There's a misunderstanding here. The object being assigned keeps a
>>> trailing list of past values and defers their deallocation to
>>> destruction. -- Andrei
>>
>> So you need an extra pointer per instance? Isn't that a big price to pay?
>
> All instances need to carry a pointer to refcount anyway, so the
> freelist could just be stored next to the refcount. The idea of creating
> that list, however, is more worrying, because it again involves
> allocations. It can get arbitrarily long.

No, the cool thing about freelists is they use free memory to chain 
things together.

Somebody please write the code already. With no code we sit forever on 
our testes speculating.

>> Is the only problem we're still trying to solve aliasing which is not
>> recognized as such and therefore doesn't bump the refcounter like it
>> should? An extra pointer would be overkill for that. Isn't it better
>> to just recognize the aliasing when it happens?
>>
>> As far as taking the address of an RcArray element, the type of which
>> element is not itself Rc'ed, it's a different problem. The only thing
>> I've been able to come up with is maybe to create a wrapper type
>> within RcArray for the individual elements, and have that type do
>> refcounting on the parent instead of itself, if that's possible.
>
> No, Andrei's proposed solution would take care of that. On assignment to
> RCArray, if the refcount goes to zero, the old array is put onto the
> cleanup list. But there can still be borrowed references to it's
> elements. However, these can never outlive the RCArray, therefore it's
> safe to destroy all of the arrays in the cleanup list in the destructor.

Yes, that's exactly right, thanks for putting it so clearly.


Andrei