Jarek Zgoda <[EMAIL PROTECTED]> wrote: > Duncan Booth napisa³(a): > >> Pretty much. If you have a __del__ method on an object then in the >> worst case the only thing that can be guaranteed is that it will be >> called zero, one or more than one times. (Admittedly the last of >> these only happens if you work at it). >> >> If it is called then is may be either immediately the last reference >> to the object is lost, or it may be later when the garbage collector >> runs (and not necessarily the first next time the garbage collector >> runs). > > Java finalizers are not called upon VM exit, only when object is swept > by GC (for example when the object is destroyed upon program exit), > the CPython docs read that this is the case for Python too. Is this > behaviour standard for all VM implementations or is > implementation-dependent (CPython, Jython, IronPython)? > Yes, CPython does reference counting so it can call __del__ immediately an object is unreferenced. The GC only comes into play when there is a reference loop involved. If an object is directly involved in a reference loop then __del__ is not called for that object, but a loop could reference another object and its __del__ would be called when the loop was collected.
Other Python implementations may behave differently: presumably Jython works as for Java (but I don't know the details of that), and IronPython uses the CLR which has its own peculiarities: finalizers are all called on a single thread which is *not* the thread used to construct the object, so if you use finalizers in a CLR program your program is necessarily multi-threaded with all that implies. Also it takes at least two GC cycles to actually release memory on a CLR object with a finalizer, on the first cycle objects subject to finalization are simply added to a list (so are again referenceable), on the second cycle if the finalizer has completed and the object is unreferenced it can be collected. CLR finalizers also have the interesting quirk that before the finalizer is called any references the object has to other objects are cleared: that allows the system to call finalizers in any order. Otherwise I think the behaviour on exit is pretty standard. If I remember correctly there is a final garbage collection to give finalizers a chance to run. Any objects which become newly unreferenced as a result of that garbage collection will have __del__ called as usual, but any which merely become unreachable and therefore would be caught in a subsequent garbage collection won't. -- http://mail.python.org/mailman/listinfo/python-list
