StreamReader/StreamWriter

[George2]

Hello everyone,


I understand there is no need to call Dispose explicitly when dealing with StreamReader/StreamWriter object instances since GC will take care of it in Finalizer method.

My question is, I want to know the benefits and potential issues of using "using" statement to deal with StreamReader/StreamWriter.


thanks in advance,
George

[TheCPUWizard]

George,

If you do not understand the difference between Dispose() and Finalize() and when each is appropriate, then you really need to go back to the books for a few weeks, and stop coding immediately.

[JonnyPoet]

...I understand there is no need to call Dispose explicitly when dealing with StreamReader/StreamWriter object instances since GC will take care of it in Finalizer method....

George,
there is a main difference between Closing a stream and disposing Streams are limited resources and you should close them when finished your current job.
So you can use Using or finlaize to get this handled and you havn't to worry about open streams e.g when an exception throws you out of your actual process.

[George2]

Sorry TheCPUWizard,


I think I understand the basic theory.

My current situation is, I am writing an Http Service and handle requests from client by using StreamReader in some function to read from InputStream of each Http request.

My previous consideration is, even if GC is not worked determistic, or there will be exception, when the Http Service stops (process stops or terminations), all resources like native handle wrapped by StreamReader could be released automatically.

What is the benefit of using "using" statement?

George,

If you do not understand the difference between Dispose() and Finalize() and when each is appropriate, then you really need to go back to the books for a few weeks, and stop coding immediately.

regards,
George

[George2]

Thanks JonnyPoet,


1.

George,
there is a main difference between Closing a stream and disposing Streams are limited resources and you should close them when finished your current job.

Please correct me if I am wrong. I have used reflector before, and Close method of Stream related classes will call Dispose method (just a wrapper to call Dispose), and this is a general Dispose pattern. Why do you think calling Dispose is different from calling Close -- "there is a main difference between Closing a stream and disposing"? I think it is the same.

2.

So you can use Using or finlaize to get this handled and you havn't to worry about open streams e.g when an exception throws you out of your actual process.

Good point. If there is exception, and in both exception handler and finally block, I do not call Close/Dispose explicitly, will Dispose/Close be called automatically during exception? Or we have to wait for GC to call Finalize?


regards,
George

[MadHatter]

the general rule (not specific to this case) is: if it implements IDisposable, call dispose as soon as you're done w/ it.

placing it in a using statement is a short hand notation. the IL produced by it places the usage in try catch finally statements that close and dispose of the object, and ensures that any exception that's thrown during use will not affect the disposal process of the stream.

there should never be a need to see how a class is implemented before choosing how to deal with it, deal with it based on its documented API because internals are not guaranteed to remain the same in successive versions of the framework.


ALSO: DON'T POST MULTIPLE TIMES TO ANSWER DIFFERENT PEOPLE, DO IT IN THE SAME POST!!!

[eclipsed4utoo]

my rule of thumb is similar to MadHatter, if it contains Dispose, then use it. it's there for a reason, right?

[George2]

Thanks eclipsed4utoo and MadHatter!


My current situation is, I am writing an Http Service and handle requests from client by using StreamReader in some function to read from InputStream of Http request.

My previous consideration is, even if GC is not worked determistic, or there will be exception, when the Http Service stops (process stops or terminations), all resources like native handle wrapped by StreamReader could be released automatically.

Even though I am not using "using" and since the traffic is low, I do not meet with any issues.

I would like to learn from you and let you anticipate what issues I will meet with if I do not use "using" in my situation?

my rule of thumb is similar to MadHatter, if it contains Dispose, then use it. it's there for a reason, right?

regards,
George

[eclipsed4utoo]

As somebody who runs their own website from their home PC(Windows XP Pro) and the website does HTTP requests, I started running into alot of issues because I wasn't disposing of the objects when I was done. I was consistently having a problem where I would get the IIS message "too many users are connected". I think this was happening because the connections where staying open, even though I called Close(). After optimizing the code to dispose of all of the objects when completed, I don't have the problem anymore.

and from Microsoft...

http://msdn.microsoft.com/en-us/library/yh598w02(VS.80).aspx

C#, through the .NET Framework common language runtime (CLR), automatically releases the memory used to store objects that are no longer required. The release of memory is non-deterministic; memory is released whenever the CLR decides to perform garbage collection. However, it is usually best to release limited resources such as file handles and network connections as quickly as possible.

[George2]

Thanks eclipsed4utoo,


1.

I think in your situation of "too many users are connected" is not because your code has bug which does not free handle, but because of GC does not free handles immediately?

2.

I think using Dispose call explicitly will solve this issue. :-)

As somebody who runs their own website from their home PC(Windows XP Pro) and the website does HTTP requests, I started running into alot of issues because I wasn't disposing of the objects when I was done. I was consistently having a problem where I would get the IIS message "too many users are connected". I think this was happening because the connections where staying open, even though I called Close(). After optimizing the code to dispose of all of the objects when completed, I don't have the problem anymore.

and from Microsoft...

http://msdn.microsoft.com/en-us/library/yh598w02(VS.80).aspx

regards,
George

[MadHatter]

Stream readers and writers are decorators around a "stream" object. stream objects are an abstraction around file, memory, and network IO's.

HTTP is a protocol and the request you're processing at some point is a set of bytes read from a socket (at a lower level). the request object's stream decorates the socket class to allow for a common "stream" like interface around sending and receiving from the socket.

if you think of the socket and hypter text transfer protocol for a second, each client request is a stateless request wherein the client opens a socket connection to the server, sends a request, waits for a response, then disconnects. server side, all of that logic is implemented for you, so ultimately your decorator reader / writer is not responsible for the underlying connection and resources, it only uses it to do what it does.

where you'll get into trouble is when YOU are the one managing the client connection, state, and lifetime, and you don't explicitly close and dispose of the connection (which closes the underlying socket). the client can terminate the connection, but your server socket will throw an exception and unless you handle that, could leave you in a bad state...


so, even if you cannot understand why... it's always a best practice to dispose of IDisposable objects when you are done, and not leave it up to the GC as to when to dispose or finalize of the object. calling dispose allows the GC to collect the items that would otherwise age before being collected, so it helps keep things tidy and puts less work on the heuristics of determining what to clean up and what to let set.

[eclipsed4utoo]

Thanks eclipsed4utoo,


1.

I think in your situation of "too many users are connected" is not because your code has bug which does not free handle, but because of GC does not free handles immediately?

2.

I think using Dispose call explicitly will solve this issue. :-)

regards,
George

1. The GC is almost never immediate. It's a periodic process.
2. That's the "optimizing" that I did.

[TheCPUWizard]

1. The GC is almost never immediate. It's a periodic process.
2. That's the "optimizing" that I did.

It is NOT a periodic process. It is a demand based process when there is memory pressure at the time of a NEW allocation.

If you dont do new allocations, GC will NEVER execute. If there is no memory pressure GC will NEVER execute.

[eclipsed4utoo]

It is NOT a periodic process. It is a demand based process when there is memory pressure at the time of a NEW allocation.

If you dont do new allocations, GC will NEVER execute. If there is no memory pressure GC will NEVER execute.

Per Microsoft..

http://msdn.microsoft.com/en-us/library/ms228629(VS.80).aspx

In C#, garbage collection is handled by the common language runtime (CLR) with similar functionality to that of the JVM. The CLR garbage collector periodically checks the memory heap for any unreferenced objects, and releases the resources held by these objects.

[dglienna]

per Microsoft...

The garbage collector keeps track of objects that have Finalize methods, using an internal structure called the finalization queue. Each time your application creates an object that has a Finalize method, the garbage collector places an entry in the finalization queue that points to that object. The finalization queue contains entries for all the objects in the managed heap that need to have their finalization code called before the garbage collector can reclaim their memory.

http://msdn.microsoft.com/en-us/libr...31(VS.71).aspx