GC Destruction Order

bitwise via Digitalmars-d-learn digitalmars-d-learn at puremagic.com
Tue May 19 16:03:02 PDT 2015


On Tue, 19 May 2015 18:47:26 -0400, Steven Schveighoffer  
<schveiguy at yahoo.com> wrote:

> On 5/19/15 5:07 PM, bitwise wrote:
>> On Tue, 19 May 2015 15:36:21 -0400, rsw0x <anonymous at anonymous.com>  
>> wrote:
>>
>>> On Tuesday, 19 May 2015 at 18:37:31 UTC, bitwise wrote:
>>>> On Tue, 19 May 2015 14:19:30 -0400, Adam D. Ruppe
>>>> <destructionator at gmail.com> wrote:
>>>>
>>>>> On Tuesday, 19 May 2015 at 18:15:06 UTC, bitwise wrote:
>>>>>> Is this also true for D?
>>>>>
>>>>> Yes. The GC considers all the unreferenced memory dead at the same
>>>>> time and may clean up the class and its members in any order.
>>>>
>>>> Ugh... I was really hoping D had something better up it's sleeve.
>>>
>>> It actually does, check out RefCounted!T and Unique!T in std.typecons.
>>> They're sort of limited right now but undergoing a major revamp in  
>>> 2.068.
>>
>> Any idea what the plans are?. Does RefCounted become thread safe?
>>
>> Correct me if I'm wrong though, but even if RefCounted itself was
>> thread-safe, RefCounted objects could still be placed in classes, at
>> which point you might as well use a GC'ed class instead, because you'd
>> be back to square-one with your destructor racing around on some random
>> thread.
>
> With the current GC, yes. RefCounted needs to be thread safe in order to  
> use it. But if we change the GC, we could ensure destructors are only  
> called in the thread they were created in (simply defer destructors  
> until the next GC call in that thread).

This seems like it could result in some destructors being delayed  
indefinitely.

>> I'm finding it hard to be optimistic about the memory model of D.
>>
>> The idea of marking absolutely everything in your program with "@nogc"
>> just to make it safe is ludicrous.
>
> That makes no sense, the GC is not unsafe.
>
> -Steve

Maybe I worded that incorrectly, but my point is that when you're running  
with the GC disabled, you should only use methods marked with @nogc if you  
want to make sure your code doesn't leak right? that's a lot of attributes  
O_O

   Bit


More information about the Digitalmars-d-learn mailing list