Destructors and Deterministic Memory Management

[Georg Wrede]

Georg Wrede wrote:
> Sean Kelly wrote:
>> dsimcha wrote:
>>> Two closely related topics here:
>>>
>>> 1.  It is often nice to be able to create a single object that works 
>>> with both
>>> GC and deterministic memory management.  The idea is that, if delete 
>>> is called
>>> manually, all sub-objects would be freed deterministically, but the 
>>> object
>>> could still safely be GC'd.  Since the destructor called by the GC can't
>>> reference sub-objects, would it be feasible to have two destructors 
>>> for each
>>> class, one that is called when delete is invoked manually and another 
>>> that is
>>> called by the GC?
>>
>> You can do this today with both Druntime on D 2.0 and Tango on D 1.0, 
>> though it isn't the most performant approach.  The code would look 
>> something like this:
>>
>> import core.runtime;
>>
>> interface Disposable
>> {
>>     void dispose();
>> }
>>
>> bool handler( Object o )
>> {
>>     auto d = cast(Disposable) o;
>>
>>     if( d !is null )
>>     {
>>         d.dispose();
>>         return false;
>>     }
>>     return true;
>> }
>>
>> static this()
>> {
>>     Runtime.collectHandler = &handler;
>> }
>>
>> If you return false from your collectHandler then the runtime won't 
>> call the object's dtor.
> 
> Err, if one has an object that needs deterministic destruction, then one 
> calls it (with say myDelete()) to have it release its resources. Until 
> then, of course, it shouldn't get collected. But in any case it won't, 
> because we obviously have a handler to it because we still haven't 
> decided to destruct it. So I assume there's something I don't understand 
> here.

s/handler/reference/

> After we're done with destructing (as in having called myDelete()), then 
> we "delete the object", or let it go out of scope. Then it becomes 
> eligible for disposal. So, what's the relevance of Disposable here?
>