finalizer

This is a fairly fine point, and I expect the answer is "it's not a hot idea to begin with" - that said, it has a points that I'm interested in regardless, if someone is kind enough to indulge. Model Code: public partial class MyEntities : ObjectContext { // the idea is if the object is in a using block, this always gets called? protected override void Dispose(bool disposing) { this.SaveChanges(); base.Dispose(disposing); } } Client Code: using(var model = new MyEntities()) { // do something // no worry about calling model.SaveChanges() } The issues I'm uncertain about are: Is Dispose the

I know that Finalize method is used by garbage collector to let object free up unmanaged resources. And from what I know, Object.Finalize is never called directly by GC (object is added to f-reachable queue during it's construction if it's type overrides the Finalize method by implementing finalizer). Object.Finalize is only called from autogenerated finalizer code : try { //My class finalize implementation } finally { base.Finalize(); // Here chain of base calls will eventually reach Object.Finalize/ } So having an arbitrary class, derived from Object, wouldn't call Object.Finalize - you need

I'm trying to make sure that my understanding of IDisposable is correct and there's something I'm still not quite sure on. IDisposable seems to serve two purpose. To provide a convention to "shut down" a managed object on demand. To provide a convention to free "unmanaged resources" held by a managed object. My confusion comes from identifying which scenarios have "unmanaged resources" in play. Say you are using a Microsoft-supplied IDisposable -implementing (managed) class (say, database or socket-related). How do you know whether it is implementing IDisposable for just 1 or 1&2 above? Are

I'm not quite understanding why there are finalizers in languages such as java and c#. AFAIK, they: are not guaranteed to run (in java) if they do run, they may run an arbitrary amount of time after the object in question becomes a candidate for finalization and (at least in java), they incur an amazingly huge performance hit to even stick on a class. So why were they added at all? I asked a friend, and he mumbled something about "you want to have every possible chance to clean up things like DB connections", but this strikes me as a bad practice. Why should you rely on something with the

As always, a lengthy problem description. We are currently stress testing our product - and we now we face a strange problem. After one to two hours, heap space begins to grow, the application dies sometime later. Profiling the application shows a very large amount of Finalizer objects, filling the heap. Well, we thought "might be the weird finalizer thread to slow" issue and reviewed for reducing the amount of objects that need to be finalized (JNA native handles in this case). Good idea anyway and reduced thousands of new objects... The next tests showed the same pattern, only one hour later

I am translating a C# class that wraps an unmanaged library to F#. I have run into the seemingly simple problem of rewriting the destructor that follows. class Wrapper { // P/Invoke ellided private SomeType x; public Wrapper() { x = new SomeType(); Begin(); } public ~Wrapper() { End(); } The simplified F# code I have at this point is as follows: type Wrapper() = [<Literal>] static let wrappedDll = "Library.dll" [<DllImport(wrappedDll , EntryPoint = "Begin")>] static extern void Begin() [<DllImport(wrappedDll , EntryPoint = "End")>] static extern void End() let x = new SomeType() do Begin() How

The function runtime.SetFinalizer (x, f interface{}) sets the finalizer associated with x to f . What kind of objects are finalized by default? What are some of the unintended pitfalls caused by having those objects finalized by default? The following objects are finalized by default: os. File : The file is automatically closed when the object is garbage collected. os. Process : Finalization will release any resources associated with the process. On Unix, this is a no-operation. On Windows, it closes the handle associated with the process. On Windows, it appears that package net can

I'm seeing an issue with some code I maintain. The code below has a private static SHA1 member (which is an IDisposable but since it's static , it should never get finalized). However, under stress this code throws an exception that suggests it has been closed: Caught exception. Safe handle has been closed" Stack trace: Call stack where exception was thrown at System.Runtime.InteropServices.SafeHandle.DangerousAddRef(Boolean& success) at System.Security.Cryptography.Utils.HashData(SafeHashHandle hHash, Byte[] data, Int32 cbData, Int32 ibStart, Int32 cbSize) at System.Security.Cryptography