class A
{
public event EventHandler AEvent;
}
class B
{
private A _foo;
private int _bar;
public void AttachToAEvent()
{
_foo.AEvent += delegate()
{
...
UseBar(_bar);
...
}
}
}
Since delegate
captures variable this._bar
, does it implicitly hold to the instance of B
? Will instance of B
be referenced through the event handler and captured variable by an instance of A
?
Would it be different if _bar
was a local variable of the AttachToAEvent
method?
Since in my case an instance of A
lives far longer and is far smaller than an instance of B
, I'm worried to cause a "memory leak" by doing this.
Ani's answer is correct. Summarizing and adding some details:
Yes. "this" is captured.
Yes.
Yes. In that case the closure object would hold on to the local; the local would be realized as a field of the closure.
You are absolutely right to worry. Your situation is already bad, but in fact the situation can be considerably worse when you have two anonymous functions in play. Right now all anonymous functions in the same local variable declaration space share a common closure, which means that the lifetimes of all closed-over outer variables (including "this") are extended as far as the longest lived of all of them. See my article on the subject for details:
http://blogs.msdn.com/b/ericlippert/archive/2007/06/06/fyi-c-and-vb-closures-are-per-scope.aspx
We hope to fix this in a hypothetical future version of C#; we could be partitioning the closures better instead of creating one big closure. However that is not going to happen any time soon.
Moreover, the "async/await" feature of C# 5 will also likely exacerbate situations in which locals end up living longer than you'd expect. None of us are thrilled with this, but as they say, the perfect is the enemy of the awesome. We have some ideas about how we can tweak the codegen of async blocks to improve the situation, but no promises.
If you add an anonymous method to an event and want to deference it, you will have to set the event to null or store your delegate in a list so you can later "-=" it from your event.
But yes, you can get a "memory leak" from objects referenced in a delegate that is attached to an event.
This is easiest understood by looking at the code generated by the compiler, which is similar to:
As can be plainly seen, the delegate created is an instance-delegate (targets an instance method on an object) and must therefore hold a reference to this object instance.
Actually, the anonymous method captures just
this
(notthis._bar
). As can be seen from the generated code, the constructed delegate will indeed hold a reference to theB
instance. It has to; how else could the field be read on demand whenever the delegate is executed? Remember that variables are captured, not values.Yes, you have every reason to be. As long as the
A
instance is reachable, theB
event-subscriber will still be reachable. If you don't want to go fancy with weak-events, you need to rewrite this so the handler is unregistered when it is no longer required.Yes, it would, as the captured variable would then become the
bar
local rather thanthis
. But assuming thatUseBar
is an instance-method, your "problem" (if you want tot think of it that way) has just gotten worse. The compiler now needs to generate an event-listener that "remembers" both the local and the containingB
object instance.This is accomplished by creating a closure object and making it (really an instance method of it) the target of the delegate.