GC object finalization not guaranteed

[Robert Jacques]

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)