[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.
http://bugzilla.ximian.com/show_bug.cgi?id=50917
--- 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
+Resolution:
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 @@
c
------- 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
+method.
+
+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
+incorrect.