Thanks for the insights *Nic*.

That's quite good - it means the plan I had is pretty much OK as it's not
breaking some magic GC-fu that I didn't know about.  I am responsible for
freeing up reference to the object, and as soon as I do that, then
magically in the background GC will take care of things.

And listening to a Disposed event, in my scheme, was all about making sure
I new when to free up the resources.

Awesome
-- 
*Phil *Cockfield




On Tue, Aug 28, 2012 at 10:26 PM, Nic Wise <n...@fastchicken.co.nz> wrote:

> 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 <p...@cockfield.net>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
>> MonoTouch@lists.ximian.com
>> 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
MonoTouch@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/monotouch

Reply via email to