[Gc] Re: Do finalizers run at exit?
axilmar at otenet.gr
Fri Dec 28 08:02:59 PST 2007
O/H Christophe Meessen έγραψε:
> Achilleas Margaritis a écrit :
>> And another question: why finalization is good after a collection, but
>> not at program exit? what's the difference? both situations seem the
>> same to me.
> The answer to this question was already given.
Nope, it was not answered :-).
I asked why finalization is permitted in one place and not permitted in
another place, where both places are equal; I did not ask why
finalization is good or bad (at least for the question you replied to).
A good program design
> should avoid relying on finalizer call of objects allocated on the heap.
> See Java for a good application of this rule.
> Here are a few reasons I thought of:
> - no control of finalize call order and time (i.e. problem with cycles)
Solved by finalizing objects in graph order, i.e. as Boehm gc does it.
> - in some case, calling finalizers is a waste of time (i.e. program
No, it's not. An O/S will cleanup the resources of a process, but it
will not magically do things the user is supposed to do. For example,
deleting a temp file.
> - slows down gc
It does not, if executed in parallel with the rest of the program.
> Suppose you have a circular doubly linked list of objects. How is the GC
> supposed to know what object to finalize first ? It will have to
> randomly pick one. But then to preserve validity of the data structure,
> one would have to add a finalizer so that each object properly remove
> itself from the list. This object detachment is a pure waste of time. It
> is particularly obvious when the data structure is destroyed when the
> program terminates.
On the other hand, suppose you have a temp file that you want to close
at the end of the program, and your temp file is represented by a
TempFile class which deletes the temp file upon its finalization. If you
don't invoke the finalizer, the temp file will not be deleted.
Furthermore, in the example you mention, if a node needs to be removed
from a double-linked list, order is irrelevant: nodes can be removed at
any order from the list.
> Thus the rule of thumb is to design your program so that it doesn't rely
> on finalizer beeing called.
No, I beg to differ. The rule of thumb should be that the programmer
should have a choice.
> The possibility to call finalizers is there because of the few
> exceptions where it is required to have them : recycle resources
> controlled by the destructed object like a file descriptor.
Which will not happen if finalizers are not invoked.
Keep in mind
> that the program can crash and that the situation where no finalizer is
> called is a possible use case.
Another important reason why finalizers should be invoked.
> I gave up smart pointers because avoiding cycles requires significant
> attention and some time more complex design than it should. Beside, in
> most case all this thread safe counter increment/decrement polka is a
> waste of cpu resource. Compare the million pointer assignments (i.e.
> iterators) that may occur in one GC cycle.
I agree with you on this and I wish I could magically transfer this
knowledge to 100s of C++ programmers who insist C++ only needs reference
counting and nothing more.
More information about the Gc