Użytkownik Shawn A. Van Ness <[EMAIL PROTECTED]> napisał: >http://www.gotdotnet.com/team/fxcop/Docs/Rules/SecurityRules/IntptrAndFinalize.html > >I struggle to comprehend the above FxCop rule. Does it make a lick of >sense to anyone?
Well, I would start with a remark that the introduction is a bit unclear: "Unmanaged references to objects do not prevent garbage collection. This rule detects errors that might occur due to an unmanaged resource being finalized while it is still in use in unmanaged code." The first sentence has no correlation with the whole issue. The second also looks a bit odd to me (in this context). >How could the finalizer decide to collect an object, if one or more >threads is currently executing code against it? (Put simply: doesn\'t >the \'this\' pointer count as a reachable reference, for the duration of >any instance-method call?) It looks like this note suggests that it does not - and when the GC detects that 'this' is no more 'touched' by the code, the object may be immediately GC-ed and then finalized, possibly long before a method returns. It also seems to me, although I would like to hear comments from experts, that this behavior would be completely safe - assuming we stay inside the managed world. Safe, although surprising and counterintuitive. And dangerous for any kind of unmanaged resources. Anyway, the problem looks to have nothing to do with callbacks from unmanaged code (although the introduction seems to suggest such a correlation). If so, it seems to also have nothing to do with 'using a resource in unmanaged code' - it could be used somehow in managed code, as well (at least, we could use IntPtr.ToPointer() and get an invalid value as the object has been finalized and IntPtr field has been zeroed). If this is true, how about managed C++? This time, it seems that the situation looks different (object's fields are used in an explicit way), and the problem does not appear. And finally, if this is true, it seems like a GC bug. In fact, in most cases finalizers are used for unmanaged resources - referring to managed objects may be dangerous (as they could have been GC-ed already). Thus, if this is true, the GC should artificially keep such objects (declaring finalizers) alive during instance method calls (i.e., add those KeepAlive calls automatically). Also, the 'certainty level' is 50% - what does it mean? I do not know when this note appeared first but I do not remember to read about such a possible problem before - most code around would be broken... Interesting but anxious. Marek =================================== This list is hosted by DevelopMentorŽ http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
