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