[Mono-bugs] [Bug 75526][Nor] Changed - [PATCH] StreamReader blocks on reading too much

[bugzilla-daemon at bugzilla.ximian.com]

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

Changed by jlarimer at gmail.com.

http://bugzilla.ximian.com/show_bug.cgi?id=75526

--- shadow/75526	2005-08-31 17:59:25.000000000 -0400
+++ shadow/75526.tmp.1089	2007-01-23 15:06:51.000000000 -0500
@@ -10,13 +10,13 @@
 Component: CORLIB
 AssignedTo: mono-bugs at ximian.com                            
 ReportedBy: gnauck at ag-software.de               
 QAContact: mono-bugs at ximian.com
 TargetMilestone: ---
 URL: 
-Summary: StreamReader blocks on reading too much
+Summary: [PATCH] StreamReader blocks on reading too much
 
 while debugging my library under windows i stumbled of following.
 I create a new StreamReader from a NetworkStream for parsing Xml.
 
 StreamReader sr = new StreamReader(myTcpClient.GetStream());
 
@@ -147,6 +147,34 @@
 data is available, and returns when more data is availble.
 
 So its not really a bug. Its only a different behaviour. Our projects
 noth rely on the MS .NET design, and i assume lots of other projects
 too. So it would be very good when the MONO Streams have the same
 behaviour and design here than the MS Streams.
+
+------- Additional Comments From jlarimer at gmail.com  2007-01-23 15:06 -------
+I've been seeing this problem too. Attached is a reproduction program 
+(srtest.cs) and a patch that fixes StreamReader.Read() to work 
+correctly (as specified in the MSDN documentation).
+
+srtest.cs output with MS.NET:
+
+  C:\proj\srtest\bin\Debug>srtest.exe
+  Server: Listening
+  Client: Connected, attempting to read 10 bytes
+  Client: Read 3 bytes
+  Server: Sent 3 bytes
+  Server: Listen thread done
+
+  C:\proj\srtest\bin\Debug>
+
+Output with Mono on Linux:
+
+  debacle:~/test$ mono ./srtest.exe
+  Server: Listening
+  Client: Connected, attempting to read 10 bytes
+  Server: Sent 3 bytes
+
+It never returns. With the attached proposed patch, it works 
+correctly. I believe this IS a bug, because the MS documentation 
+states that StreamReader.Read() should return the amount of data 
+available, and only block if there is no data available.