[Mono-bugs] [Bug 31333][Nor] Changed - GC problem with Console.WriteLine in the finalization code.
29 Oct 2002 00:11:04 -0000
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 firstname.lastname@example.org.
--- shadow/31333 Sun Oct 27 12:54:43 2002
+++ shadow/31333.tmp.21066 Mon Oct 28 19:11:04 2002
@@ -139,6 +139,42 @@
------- Additional Comments From email@example.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 firstname.lastname@example.org 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.