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?
