GC object finalization not guaranteed

[Don]

Robert Jacques wrote:
> On Sat, 18 Apr 2009 16:25:32 -0400, Don <nospam at nospam.com> wrote:
> 
>> Leandro Lucarella wrote:
>>> Robert Jacques, el 18 de abril a las 11:56 me escribiste:
>>>> On Sat, 18 Apr 2009 11:24:14 -0400, Leandro Lucarella 
>>>> <llucax at gmail.com> wrote:
>>>>> I've just found out[1] this[2]:
>>>>>
>>>>>     The garbage collector is not guaranteed to run the destructor for
>>>>>     all unreferenced objects.
>>>>>
>>>>> Is there any reason why D can't guarantee that all finalizers will be
>>>>> called, at least when the program ends?
>>>> Well, a couple of quick tests show that under normal situations (i.e.
>>>> normal program termination and termination from an exception) the
>>>> finalizers do run (D2). However, if a finalizer throws an exception,
>>>> then the rest of the finalizers aren't called. Also, if you call
>>>> std.c.stdlib.exit, the finalizers won't run.
>>>  Well, I'm not talking about experimentation, I'm talking about 
>>> source code
>>> ;)
>>>  The current GC implementation don't call finalizers for data that's 
>>> still
>>> reference when the program *ended* (this is allowed by the specs, so 
>>> it's
>>> fine, the question is why it's allowed by the specs).
>>
>> I don't understand why D even has finalizers. Can they do anything 
>> useful?
> 
> Yes. I use them to manage GPU memory/resources. Another are wrapper 
> classes around manually allocated arrays (to avoid the false pointer 
> problem with very large arrays). Both of these examples don't require 
> finalization at program termination (unlike file handles/sockets, etc)

OK, those both make perfect sense -- they are both memory issues. It 
still seems that gc is perfect for memory, but no good for anything else.