[Mono-bugs] [Bug 31333][Nor] Changed - GC problem with Console.WriteLine in the finalization code.

[bugzilla-daemon@rocky.ximian.com]

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

Changed by miguel@ximian.com.

http://bugzilla.ximian.com/show_bug.cgi?id=31333

--- shadow/31333	Sun Oct 27 12:54:43 2002
+++ shadow/31333.tmp.21066	Mon Oct 28 19:11:04 2002
@@ -139,6 +139,42 @@
 Patch?
 
 
 ------- Additional Comments From miguel@ximian.com  2002-10-27 12:54 -------
 The patch looks good to me.  I will include this in our version of
 libgc that we ship.  Thanks for looking into this ettore.
+
+------- Additional Comments From miguel@ximian.com  2002-10-28 19:11 -------
+From Hans Boehm:
+
+Thanks for pointing me at this.  Please consider this response as
+public; if you think it's appropriate to attach to the bug report,
+please do so.
+
+Gcj ran into the same issue, more or less.  I don't consider it a GC
+bug, and I don't think it's a good idea to work around it there, at
+least not as suggested here.
+
+If I recall the language in the C# etc. standards correctly, this is
+really a combination of two things:
+
+1) The standard is sloppy in defining what finalizers do.  Finalizers
+should NEVER be invoked from an allocating thread, since that can leas
+to deadlocks etc.  Finalizers are logically executed asynchronously,
+and correct finalizers typically need to acquire locks.  Executing
+them in the context of a thread that may already hold locks is WRONG. 
+Most Java implementations got this wrong the first time around, though
+the Java spec actually got it right.  Gcj fixed this not too long
+ago.  (I am in the process of finishing a paper that discusses in more
+detail.  It will be presented at POPL '03.)
+
+2) It looks like Mono actually allows the collector to invoke
+finalizers, probably because that appears to be consistent with the
+spec.  (Hopefully it's not consistent with what the Microsoft
+implementation does, but I don't know.)  It should set up one or more
+threads whose job is exclusively to run finalizers, set
+GC_finalize_on_demand to nonzero, and set GC_finalizer_notifier to
+point to a function which notifies that thread that there may be
+runnable finalizers.  (This leaves some more subtle issues related to
+invoking finalizers from file open procedures and the like, but it
+should at least get you close.)  There is some argument that the GC
+default be different, but that causes release compatibility issues.