[Mono-bugs] [Bug 74840][Maj] New - Blocking Read() does not return if NetworkStream is closed underneath it
bugzilla-daemon@bugzilla.ximian.com
bugzilla-daemon@bugzilla.ximian.com
Thu, 5 May 2005 15:46:01 -0400 (EDT)
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 joeshaw@novell.com.
http://bugzilla.ximian.com/show_bug.cgi?id=74840
--- shadow/74840 2005-05-05 15:46:00.000000000 -0400
+++ shadow/74840.tmp.30327 2005-05-05 15:46:00.000000000 -0400
@@ -0,0 +1,32 @@
+Bug#: 74840
+Product: Mono: Class Libraries
+Version: 1.1
+OS:
+OS Details:
+Status: NEW
+Resolution:
+Severity:
+Priority: Major
+Component: CORLIB
+AssignedTo: mono-bugs@ximian.com
+ReportedBy: joeshaw@novell.com
+QAContact: mono-bugs@ximian.com
+TargetMilestone: ---
+URL:
+Cc:
+Summary: Blocking Read() does not return if NetworkStream is closed underneath it
+
+If in one thread you are doing a blocking Read() on a NetworkStream and in
+another thread you close the stream, I would expect that the connection
+would be closed and the Read() would return 0 bytes read. Instead, the
+connection stays open and continues to block, and if the client sends any
+data exceptions are thrown.
+
+I'm attaching a test case. Run it and connect to it using telnet on port
+8888 as soon as it starts. 10 seconds after it starts it will call Close()
+on the TcpClient (or UnixClient), which in turn closes the NetworkStream
+underneath it. Notice on the server side that it does not say "Read 0
+bytes", meaning that the Read() call is still blocking. Also notice on the
+client side that the connection has not been disconnected. Type anything
+in on the client side after the connection has been "closed" and you'll see
+exceptions on the server side.