idisposable

Cancelling a Task when an object is Finalized

不羁的心 提交于 2019-12-04 12:53:39
I have a class which starts a Task and want to ensure that the Task stops when the object is garbage collected. I have implemented the IDisposable pattern to ensure that if the object is disposed manually or used within a using block, then the Task stops correctly. However , I cant guarantee that the end user will call Dispose() or use the object within a using block. I know that the Garbage Collector will eventually call the Finalizer - does this mean that the task is left running? public class MyClass : IDisposable { private readonly CancellationTokenSource feedCancellationTokenSource = new

Thread-Safety of Dispose methods?

巧了我就是萌 提交于 2019-12-04 11:30:23
问题 MSDN documents the thread-safety of instances members of BCL types pretty well, but I have never really seen information indicating how the Dispose method of IDisposable types can be called. Is the Dispose method a) guaranteed to be thread-safe for all classes, b) never guaranteed to be thread-safe, c) guaranteed to be thread-safe for some classes (if so, where is this specifically documented)? Finally, if the Dispose method is guaranteed to be thread-safe, does that mean I have to put a lock

IDisposable, Finalizers and the definition of an unmanaged resource

不打扰是莪最后的温柔 提交于 2019-12-04 08:40:17
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

Should I bother calling dispose on objects which share lifetime of process?

亡梦爱人 提交于 2019-12-04 03:24:24
I am aware that all objects which implement IDisposable should be disposed of as soon as they are no longer needed in order to free the memory used by their unmanaged resources. My question relates to objects which I know for a fact will live until the host process itself is terminated. Would it make any difference if I dispose of them or not? Is there any chance of memory not being freed when the process dies? What about GDI objects? Would the GDI handles be freed when the process dies even if they were not disposed? I fully understand that it is good practice to dispose of all objects

Icon.FromHandle: should I Dispose it, or call DestroyIcon?

橙三吉。 提交于 2019-12-04 03:20:20
问题 I use Win32 SHGetFileInfo to get a handle to the icon belonging to a certain file. There are a lot of descriptions how to do this, also on stackoverflow, for instance: Get icons used by shell After calling the function you have a struct with the handle to the Icon. Using the static method Icon.FromHandle I can convert it to an object of class System.Drawing.Icon. This class implements System.IDisposable. Proper usage would be like: using (Icon icon = Icon.FromHandle(shFileInfo.hIcon)) { // do

ClientBase doesn't implement IDisposable member

房东的猫 提交于 2019-12-04 02:57:04
How is it possible for the System.ServiceModel.ClientBase abstract class to implement IDisposable Interface if the Dispose() Method declaration is not visible/declared? If I try to do the same I get an error and can't compile abstract class ATeste : IDisposable { } 'ATeste' does not implement interface member 'System.IDisposable.Dispose()' I'm using VS 2010 and Framework 4.0. Check the ClientBase declaration: // Summary: // Provides the base implementation used to create Windows Communication Foundation // (WCF) client objects that can call services. // // Type parameters: // TChannel: // The

IDisposable, does it really matter

非 Y 不嫁゛ 提交于 2019-12-04 02:34:06
Coming from C/C++ a long time ago I still have a habit of ensuring that all resources are cleaned up correctly. I always ensure Dispose is called on IDisposable classes and implement Dispose patterns in my classes containing disposable objects. However, in my environment I'm more or less the only one doing this. Others just don't understand what I'm doing and think my code is more difficult to understand. They just create database connections, open streams etc without calling Close or Dispose. Sometimes they set a local or member variable to "Nothing" at the end of a method (guess their

When would dispose method not get called?

喜你入骨 提交于 2019-12-04 01:24:14
问题 I was reading this article the other day and was wondering why there was a Finalizer along with the Dispose method. I read here on SO as to why you might want to add Dispose to the Finalizer. My curiousity is, when would the Finalizer be called over the Dispose method itself? Is there a code example or is it based on something happening on the system the software is running? If so, what could happen to not have the Dispose method run by the GC. 回答1: The purpose of the finaliser here is simply

IDisposable implementation - What should go in 'if (disposing)'

不打扰是莪最后的温柔 提交于 2019-12-03 23:29:50
I have been fixing some memory leak issues in a winforms application and noticed some disposable objects that are not Disposed explicitly (developer hasn't called Dispose method). Implementation of Finalize method also doesn't help because it doesn't go in if (disposing) clause. All the static event unregistering and collection clearing have been put in if (disposing) clause. The best practice is calling the Dispose if the object is disposable, but unfortunately this happens sometimes If there are unmanaged objects, static event handlers and some managed collections that needs to clear when

How to use disposable view models in WPF?

那年仲夏 提交于 2019-12-03 17:50:32
问题 How do I ensure view models are properly disposed of if they reference unmanaged resources or have event handlers such as handling elapsed on a dispatcher timer. In the first case, a finaliser is an option, although not ideal, but in the latter, it will never be called. How can we tell when there is no longer a view attached to the view model. 回答1: I accomplished this by doing the following: Removing the StartupUri property from App.xaml. Defining my App class as follows: public partial class