[Mono-bugs] [Bug 50917][Wis] Changed - GC.KeepAlive's scope only lasts until it is called.

bugzilla-daemon@bugzilla.ximian.com bugzilla-daemon@bugzilla.ximian.com
Thu, 13 Nov 2003 12:20:34 -0500 (EST)

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 bmaurer@users.sf.net.


--- shadow/50917	2003-11-13 04:51:59.000000000 -0500
+++ shadow/50917.tmp.1314	2003-11-13 12:20:34.000000000 -0500
@@ -1,13 +1,13 @@
 Bug#: 50917
 Product: Mono/Runtime
 Version: unspecified
 OS: unknown
 OS Details: 
-Status: RESOLVED   
-Resolution: NOTABUG
+Status: REOPENED   
 Severity: Unknown
 Priority: Wishlist
 Component: misc
 AssignedTo: mono-bugs@ximian.com                            
 ReportedBy: bmaurer@users.sf.net               
 QAContact: mono-bugs@ximian.com
@@ -64,6 +64,35 @@
 ------- Additional Comments From gonzalo@ximian.com  2003-11-13 04:51 -------
 The order in which finalizers are called is not guaranteed.
 GC.KeepAlive is a noop that guarantees that GC will not collect the
 specified variable until after the call.
+------- Additional Comments From bmaurer@users.sf.net  2003-11-13 12:20 -------
+Note that i call:
+	GC.Collect ();
+	GC.WaitForPendingFinalizers ();
+*AFTER* the keepalive has expired. This means that I am *guaranteed* 
+that the finalizer will be called (because it will do a FULL garbage 
+collection) in this garbage collection. MS's behavior is consistant 
+here, no matter how I do it, the item is always collected durring the 
+collection when it has not been kept alive.
+This would be bad in a case where we did something like this:
+1) allocate a resource
+2) use it in unmanaged code (where, without the keepalive the 
+resource would be finalized)
+3) call GC.KeepAlive in order so that the object is not finalized in 2
+4) preform a lengthy operation
+In ms, the object would be a canidate for garbage collection durring 
+(4), however, with mono it is only a canidate when control leaves the 
+The use of the forced gc is not because this is how it would happen 
+in an app, but to show that the GC will not consider the resource for 
+finalization until after control leaves the method, which is