GC object finalization not guaranteed

[Unknown W. Brackets]

Well, I guess it would be doable to guarantee destruction, but *only* if 
order of destruction was not guaranteed.

In other words, at the end, the GC would not scan, it would just 
destroy.  Scanning is a problem, due to cycles and various other things, 
but destroying all roots would be potentially doable.

I disagree that a log file needs guaranteed finalization, however.  It's 
when you think that way that you ignore the possibility of hardware 
failure.  I'm a server guy - and all the daemons I use log immediately 
to the filesystem, without buffering.  Anything else would be unacceptable.

I may be wrong, but I'm pretty sure std.stream's files do not work as 
you suggest.  BufferedFile may, but I do not think File does (aside from 
OS buffers and journals which are fine; an fsync is not mandatory.)

-[Unknown]


Leandro Lucarella wrote:
> Unknown W. Brackets, el 18 de abril a las 16:16 me escribiste:
>> The simple solution is this:
>>
>> 1. If your class object only involves memory, freed OS handles, etc., it
>> should be used as-is.  This is most class objects.  Destructors are
>> needed to clamp resource use (see File class.)
> 
> A File class implementation, for instance, can loose data if they use
> buffers. For example:
> 
> class File
> {
> 	//...
> 
> 	~this()
> 	{
> 		this.flush(); // write remaining buffered data
> 		close(handle);
> 	}
> }
> 
> In this case, the OS will close the handle, but the data will not be
> written.
> 
> So I guess this kind of things has to go in your 2nd group.
> 
> And this is a good example for a valid use that will break if guaranteed
> finalization is not provided. A log file is a good example of an object
> that lasts for all the program lifetime and needs guaranteed finalization.
> 
>> 2. If your class object involves hardware handles, transactional
>> assurance, or data integrity, it must be scoped.  This is the same as it
>> was in C, except D has better constucts for it (see scope.)
>>
>> I don't see the problem.  For the majority of objects that only involve
>> memory, life is easier.  For the rest, life is still easier (just not as
>> much.)
> 
> Ok, I agree. Do you see any problems with support to guaranteed
> finalization?
> 
> My proposal is:
> a) Add to the specs that finalization is guaranteed, in the worse case at
>    program termination.
> b) Standarize the gc_setTermHandlerDepth() (or whatever the name is)
> c) Use a "finalize all the live data" at program exit as a default for
>    the TermHandlerDepth (without running a collection, but this is
>    completely implementation dependant).
> 
> Comments?
>