RCArray is unsafe

[Andrei Alexandrescu via Digitalmars-d]

On 3/2/15 3:22 PM, Andrei Alexandrescu wrote:
> On 3/2/15 2:57 PM, Walter Bright wrote:
>> On 3/2/2015 1:09 PM, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm at gmx.net>"
>> wrote:
>>> "I have discovered a marvellous solution, but this post is too short
>>> to describe
>>> it."
>>
>> Fortunately, Fermat (er, Andrei) was able to pass along his dazz idea to
>> me this afternoon, before he expired to something he had to attend to.
>> We were both in the dumps about this problem last night, but I think he
>> solved it.
>>
>> His insight was that the deletion of the payload occurred before the end
>> of the lifetime of the RC object, and that this was the source of the
>> problem. If the deletion of the payload occurs during the destructor
>> call, rather than the postblit, then although the ref count of the
>> payload goes to zero, it doesn't actually get deleted.
>>
>> I.e. the postblit manipulates the ref count, but does NOT do payload
>> deletions. The destructor checks the ref count, if it is zero, THEN it
>> does the payload deletion.
>>
>> Pretty dazz idea, dontcha think? And DIP25 still stands unscathed :-)
>>
>> Unless, of course, we missed something obvious.
>
> And since an RCArray may undergo several assignments during its lifetime
> (thus potentially needing to free several chunks of memory), the arrays
> to be destroyed will be kept in a freelist-style structure. Destructor
> walks the freelist and frees the chunks.

We may apply the same principle (memory may only be freed during 
destruction) to DIP74. If we figure a cheap way to keep a freelist of 
objects to be deallocated, we can borrow multiple times without a 
reference count add. But I didn't think this through yet. -- Andrei