This post originated from an RSS feed registered with .NET Buzz
by Sam Gentile.
Original Post: Maoni:Clearing up some confusion over finalization and other areas in GC
Feed Title: Sam Gentile's Blog
Feed URL: http://samgentile.com/blog/Rss.aspx
Feed Description: .NET and Software Development from an experienced perspective - .NET/CLR, Rotor, Interop, MC+/C++, COM+, ES, Mac OS X, Extreme Programming and More!
> Finalizers are only there so you can release your native resources. It’s by design not to do stuff with other >managed objects because they would be taken care of by GC.
Right and this is about it for Finalizers. A lot of people think you need them all the time. You don't need them at all if you don't have unmanaged resources. And Dispose is a lot better but Maoni is correct in you cannot guarentee someone will call it.
> 3)When the finalizer thread runs the finalizers - Each time we do a GC, we would see if there are any objects whose finalize method needs to run, if so we add it to the freachable queue and set an event to wait up the finalizer thread. Generally if a managed app is doing work, it will trigger GCs so this means whenever you trigger a GC, the finalizer thread, if it’s not already working, will immediately be aware that there are finalizers to run. The finalizer thread doesn’t wake up at “some random point of time in the future”. When it’s waken up is well defined.
But the key thing here is it's not determistic. Who knows when the GC will run? The point is not to have critical native resources where their time of release is important.
> So what if a finalizer takes a long time to run? Yes it would block the finalizers behind it from running. But remember we said you should only release native resources in your finalize method which should be fast.
Right, don't go factoring prime numbers in your finalizer-)
Previous Topic
