auto classes and finalizers

[kris]

Sean Kelly wrote:
> kris wrote:
> 
>> Jarrett Billingsley wrote:
>>
>> Interesting. It does appear to do that now, whereas in the past it 
>> didn't. I remember a post from someone complaining that it took 5 
>> minutes for his program to exit because the GC was run to completion 
>> on all 10,000,000,000 objects he had (or something like that). The 
>> "fix" for that appeared to be "just don't cleanup on exit", which then 
>> sidestepped all dtors. It seems something changed along the way, since 
>> dtors do indeed get invoked at program termination for a simple test 
>> program (not if an exception is thrown, though). My bad.
>>
>> Does this happen consistently, then? I mean, are dtors invoked on all 
>> remaining Objects during exit? At all times? Is that even a good idea?
> 
> 
> Yes, yes, yes, maybe :-)  It's the call to gc.fullCollectNoStack in 
> gc_term.  There are alternatives that might work nearly as well (ie. the 
> techniques you've used in the past) if shutdown time is an issue.
> 
>> That doesn't mean it should know about your design but, there again, 
>> it shouldn't abort it either. That implies any additional GC 
>> references held by a dtor Object really should be valid whenever that 
>> dtor is invoked. The fact that they're not relegates dtors to having 
>> insignificant value ~ which somehow doesn't seem right. Frankly, I 
>> don't clearly understand why they're in D at all ~ too little 
>> consistency.
> 
> 
> Because not having them tends to inspire people to invent their own, 
> like the dispose() convention in Java.  Having language support is 
> preferable, even if the functionality isn't terrific.

Right :)

That's why what Mike suggests make sense to me ~ only have dtor support 
for those classes that can actually take advantage of it, and have that 
enforced by the compiler. If, for example, one could also instantiate 
RAII classes at the global scope, then that would take care of loose 
ends too.

If that also makes the GC execute faster, then so much the better.


>>> Yeah, I was thinking about that, maybe instead of just looping 
>>> through all class instances linearly and deleting everything, just 
>>> keep running GC passes until the regular GC pass has no effect, and 
>>> brute force the rest. In this way, my method of "not deleting other 
>>> objects in dtors" would delete the instance of the LinkedList on the 
>>> first pass, and then all the Nodes on the second, since they are now 
>>> orphaned. 
>>
>>
>> Yep
>>
>> If references were still valid for dtors, and dtors were invoked in a 
>> deterministic manner, perhaps all we'd need is something similar to 
>> "scope(exit)", but referring to a global scope instead? Should the 
>> memory manager take care of the latter?
> 
> 
> In most cases this would work, but what about orphaned cycles?  The GC 
> would ultimately just have to pick a place to start.  Also, I think 
> disentangling a complex web of references could be somewhat time 
> intensive, and collection runs are already too slow :-)

I'd assumed it already followed a dependency tree to figure out the 
collectable allocations? But even so, it's probably better to not do any 
of that at all (and do what Mike suggests instead).