My understanding, and I may be wrong (quite likely, actually):
Dispose is called when the object goes out of a using scope. That bit is
deterministic - if you do this:
using (var fff = new Foo())
{
}
Dispose is always called at the end of that block. Same if you set it to
null; HOWEVER the GC isn't deterministic, you don't know when it'll happen.
In MT, I think it's quite aggressive, so it may be quite quickly, but it
also may not be.
However, if you have:
var list = new List<Foo>();
using (var foo = new Foo())
{
list.Add( foo );
}
At this point, the list has a reference to foo , but it's dispose has
been called. If it had resources, they have been free'ed, but it's NOT
going to be GC'ed, as the list has a reference.
And to my (non) surprise, the C# docs have a good para on it :)
http://msdn.microsoft.com/en-us/library/yh598w02.aspx
You can instantiate the resource object and then pass the variable to the
using statement, but this is not a best practice. In this case, the object
remains in scope after control leaves the using block even though it will
probably no longer have access to its unmanaged resources. In other words,
it will no longer be fully initialized. If you try to use the object
outside the using block, you risk causing an exception to be thrown. For
this reason, it is generally better to instantiate the object in the
using statement
and limit its scope to theusing block.
For one thing, I'd suggest you clear the event once you have called it -
save's having a reference to another class (which may not be GC'able)
keeping this one around. Or work out how to do a WeakReference event. Use
an Action maybe?
IDisposable has little to do with the GC - it's all about making sure
resources are cleaned up properly. Normally, it calls dispose then goes out
of scope, so the GC gets it, but if you keep a reference around, it'll not
get GC'ed, even tho it HAS been disposed of.
Does that make sense?
N
On Mon, Aug 27, 2012 at 9:56 PM, Phil Cockfield <[email protected]> wrote:
> I have a scenario where in one region of the app I have a collection
> managing models. In other places (ie, within Controllers) I have
> manipulation and lifecycle management of those models. A controller may
> dispose of a model.
>
> It would be clean for the collection to be alerted via an event when a
> model is disposed of, so I can do things like remove this disposed object
> from the collection.
>
>
>
> class Foo : NSObject
> {
>
> public event EventHandler Disposed;
>
>
> protected override void Dispose(bool disposing)
> {
>
> base.Dispose(disposing);
> if (disposing && Disposed != null) {
> // Alert listeners who might want to clean up state
> // based on the disposal of this instance.
> Disposed(this, new EventArgs());
> }
>
> }
> }
>
>
>
> *Question*: I'm wondering, is this a recipe for a memory leak?
>
> If I have something listening to a *Disposed *event, and then at the
> moment that object is disposed of, some other reference kicks off into
> action using the object. Would that pull it out of the queue for the GC to
> deal with?
>
> Or once *Dispose* has been called, is the end inexorable?
>
> I'm not doing any actual work with it - I'm just getting it out of my
> collection and clean up associated state.
>
> Thanks for any insights guys!
>
> --
> *Phil *Cockfield
>
>
>
>
> _______________________________________________
> MonoTouch mailing list
> [email protected]
> http://lists.ximian.com/mailman/listinfo/monotouch
>
>
--
Nic Wise
t. +44 7788 592 806 | @fastchicken | http://www.linkedin.com/in/nicwise
b. http://www.fastchicken.co.nz/
mobileAgent (for FreeAgent): get your accounts in your pocket.
http://goo.gl/IuBU
Trip Wallet: Keep track of your budget on the go: http://goo.gl/ePhKa
Earnest: Self-employed? Track your business expenses and income.
http://earnestapp.com
Nearest Bus: find when the next bus is coming to your stop.
http://goo.gl/Vcz1p
London Bike App: Find the nearest Boris Bike, and get riding!
http://goo.gl/Icp2
_______________________________________________
MonoTouch mailing list
[email protected]
http://lists.ximian.com/mailman/listinfo/monotouch
