Destructor nonsense on dlang.org

[Michel Fortin]

On 2012-05-24 14:35:45 +0000, Alex Rønne Petersen <alex at lycus.org> said:

> On 24-05-2012 14:43, Michel Fortin wrote:
>> I think it means that objects not collected when the program terminates
>> will never be, and thus the destructor will not be called.
> 
> That's silly. Microsoft .NET and Mono have been running finalizers on 
> runtime shutdown for a long time without problems.
> 
>> There's also the issue of false pointers that can prevent some objects
>> from being collected.
> 
> Right, but I think if we guarantee finalization at shutdown, that 
> shouldn't matter.

.NET is a virtual machine which has total control of all the code that 
runs. D has to work with the C runtime and other non-D code that might 
use D code more or less directly.

The interesting question is *how* do they do it without causing 
thread-safety issues? Perhaps they wait until all threads have been 
terminated, or perhaps they're unsafe too. Would doing the same be 
appropriate for D? Does this mean we can't use anything using static 
and global variables in destructors because they might have been 
finalized? If so, how does the compiler detects this?

If there's a way and it is not overly costly in performance, it might 
be a good idea. But we're not in a virtual machine, there are more 
constrains we must abide to and we might have to make different 
compromises.

Enlarging the scope of all this, there is already some impending 
problems with how destructors are handled in D that can easily create 
low-level races. And this applies to struct destructors too, when the 
struct is put on the heap or is a member of an object. We're in the 
need of a global solution for all this.

<http://d.puremagic.com/issues/show_bug.cgi?id=4621>
<http://d.puremagic.com/issues/show_bug.cgi?id=4624>


>> More generally, you can't really count on the destructor being called
>> because the GC is free to decide when to recycle memory. An
>> implementation that never collects and always allocate new memory is a
>> perfectly valid GC implementation, even though it might not be very
>> practical in most cases.
> 
> Even such an implementation should free all memory at shutdown, and, at 
> that point, run finalizers.

Well, not according to the current spec.

It could make sense to do so, although I'm not sure. Freeing "external" 
resources can mean many things: if we're talking about externally 
allocated memory, open files, sockets, mutexes, etc., there's no need 
to finalize that at the end of the program: the OS will do the cleanup 
for us. If we're talking about advisory locks on files, then there's 
definitely a need to clear the lock, although I'm not sure it makes 
sense to make the release dependent on a non-deterministic GC.

So I'm curious, what resource are we trying to free here?


-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/