dotgnu-pnet
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Pnet-developers] Destructors are not being called - bug or usage er


From: Norbert Bollow
Subject: Re: [Pnet-developers] Destructors are not being called - bug or usage error?
Date: Mon, 17 May 2004 16:22:05 +0200

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Rhys Weatherley <address@hidden> wrote:

> On Monday 17 May 2004 06:21 am, Norbert Bollow wrote:
> > Would it be possible for our engine to guarantee that all finalizers
> > are called prior to exit?
> >
> > How hard would that be to implement?
> 
> Impossible.  If there is a pointer to the object left over in a
> register or on the system stack, or an integer value than just
> happens to look like a pointer to an object, then the object will be
> retained by the conservative garbage collector no matter what you do. 
> 
> But, you are welcome to try to devise an solution to the guaranteed 
> finalization problem that 50 years of GC research has been unable to
> find.  Let me know when you have a patch. :-)

Huh? I haven't been able to find any references to this "guaranteed
finalization problem", and don't see how this can be a hard computer
science problem.  I mean, one could have a linked list of all objects
that will eventually need finalization. (An object would be added to
this list upon object creation, or upon a call to ReRegisterForFinalize),
and removed from the list after it's been finalized or upon an
explicit call to SuppressFinalize).

Then immediately prior to exit, the runtime engine could put itself
into a state which does not allow the creation of objects that require
finalization, and then walk that list.

I'd think that there's probably a better solution (i.e. one with less
bookkeeping overhead), the above argument is just meant to show that I
don't see how this can be a hard problem in principle.

BTW I found a claim from Brian Harry <address@hidden> at
http://www.socalnetug.org/reference/determ_final.htm that Microsoft's 
runtime engine actually has that nice property that I'd desire to see
in our runtime engine, even though they failed to clearly state the
guarantee in their docs:


 : A tracing collector definitely makes some weaker promises than ref
 : counting does. It is a somewhat more "lazy" system with respect to
 : executing termination code. Objects have "Finalizer" methods that are
 : executed when the object is no longer reachable by the
 : program. Tracing has the advantage that cycles are not an issue. It
 : also has the huge advantage that assigning a reference is a very
 : simple move operation (more on this in a minute). The price that you
 : pay for this is that there is no promise about termination code
 : running "immediately" after a reference is no longer used. However, I
 : think there is a bunch of confusion about what IS promised (caused
 : largely by our docs and due to some bugs in the pre-release causing
 : finalizers not to be called on shutdown :)). The truth is that for
 : "well behaved" programs, the finalizers will be called for
 : objects. An ill-behaved program is one that crashes or puts the
 : finalizer thread in an infinite loop, etc. Our docs are overly
 : cautious about promises in this respect. If you have an object with a
 : finalizer, the system will call it. This doesn't address the issue of
 : deterministic finalization, but is important to understand that
 : resources will get collected and finalizers are a very valuable way
 : of preventing resource leaks in a program.


Greetings, Norbert.

- -- 
Founder & Steering Committee member of DotGNU, see http://dotgnu.org/
Free Software Business Strategy Guide   --->  http://FreeStrategy.info
Norbert Bollow, Weidlistr.18, CH-8624 Gruet (near Zurich, Switzerland)
Tel +41 1 972 20 59        Fax +41 1 972 20 69       http://norbert.ch
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAqMptoYIVvXUl7DIRApfcAJ9RKyk8H9lot3q+g1RoKy3uETuQwACcCTCI
A29XpDULmgTLdXDmM4FTJg0=
=CFWQ
-----END PGP SIGNATURE-----


reply via email to

[Prev in Thread] Current Thread [Next in Thread]