Passing IDisposable as a parameter

Question

Is it good practice to pass IDisposable as a parameter to a method and delete it inside that method. This is inevitable when you need to use multiple threads. Well, best practices say that the owner (caller) should dispose of it.

eg.

public void MyMethod(MyClass reader){ using(reader){ //some code } } 

What if the owner (thread creation) no longer exists? For instance.

 interface IReader : IDisposable { string Read(); } public class MyReader : IReader { public string Read() { return "hellow world"; } public void Dispose() { //dispose code } } 

Here you find the problem ...

 public void Start() { MyReader[] readerSet = new MyReader[5]; for (int i = 0; i < readerSet.Length; i++) { readerSet[i] = new MyReader(); } foreach (IReader reader in readerSet) { ThreadPool.QueueUserWorkItem(new WaitCallback(Run), reader); } //exit after creating threads } public void Run(Object objReader) { IReader reader = (IReader)objReader; using (reader) { //use the reader } } 

Answer 1

I think you better take a delegate to create to ensure that the object is deleted.

Example

 public void Start() { var makeReader = new Func<IReader>(() => new MyReader()); for (int i = 0; i < 5; i++) { ThreadPool.QueueUserWorkItem(Run, makeReader); } } public void Run(Object state) { var makeReader = (Func<IReader>)state; using (var reader = makeReader()) { //use the reader } } 

Answer 2

No, the owner must dispose of it. The owner is usually the object that created the IDisposable instance in the first place. You can read about the best IDisposable examples here .

Transport any available disposable fields defined in your type from the Dispose method. You must call Dispose () on any field whose life cycle controls your object. For example, consider the case where your object owns a private TextReader field. In your Dispose type, you must call the TextReader Dispose object, which will in turn manage its one-time fields (stream and coding for example), etc. If they are implemented inside the Dispose (bool disposing) method, this should only happen if the delete option does not allow true touches of other managed objects during finalization. Also, if your object does not own this one-time object, it should not try to get rid of it, as other code may still rely on the fact that it is active. . Both of these can lead to subtle errors to detect.

It might be a good idea to minimize the transfer of IDisposable instances so you don't have to think too much about the owners.

Answer 3

It completely depends on your specific situation.

As a rule, the "owner" should dispose of the object, but it is your task to find out who it is. Perhaps it was not the creator, and it may not be challenging in your case.

Answer 4

At any point in time from its creation to the call of Dispose, any instance of IDisposable should have only one owner who will be responsible for its removal. As a rule, the owner of IDisposable will be the entity that created it, but there are times when it can be useful if the side of the object does not own the ID ofposable to another object. Consider, for example, the following two hypothetical classes:

1. SoundSource, which implements the GetAudio method, which returns the following "n" sound samples. SoundSource implements IDisposable because it can be used to stream audio from a file; if it is not installed correctly, the file will not be closed.
2. AsyncSoundPlayer, which implements the PlaySound method, which takes a SoundSource and starts playing it, interrupting any previous playback sound.

   In many situations, the routine loading SoundSource will not care when this is done; perhaps it would be more convenient for the playback routine to take responsibility for SoundSource. Please note that in some cases, a program requesting playback may wish to retain ownership of SoundSource. The best approach is to allow the means by which the caller can indicate whether he wants to retain or transfer ownership of the transferred IDisposable.