* DevNotes: Add entry cgf-000008.

* fhandler_tty.cc (bytes_available): Simplify by returning the number of bytes
available in the message unless that is zero.

1 files changed, 32 insertions, 0 deletions

diff --git a/winsup/cygwin/DevNotes b/winsup/cygwin/DevNotes
index e1d2b3f61..da9cea13e 100644
--- a/winsup/cygwin/DevNotes
+++ b/winsup/cygwin/DevNotes
@@ -1,3 +1,35 @@
+2012-05-14  cgf-000008
+
+<1.7.16>
+- Fix hang when zero bytes are written to a pty using
+  Windows WriteFile or equivalent.  Fixes:
+  http://cygwin.com/ml/cygwin/2012-05/msg00323.html
+</1.7.16>
+
+cgf-000002, as usual, fixed one thing while breaking another.  See
+Larry's predicament in: http://goo.gl/oGEr2 .
+
+The problem is that zero byte writes to the pty pipe caused the dread
+end-of-the-world-as-we-know-it problem reported on the mailing list
+where ReadFile reads zero bytes even though there is still more to read
+on the pipe.  This is because that change caused a 'record' to be read
+and a record can be zero bytes.
+
+I was never really keen about using a throwaway buffer just to get a
+count of the number of characters available to be read in the pty pipe.
+On closer reading of the documentation for PeekNamedPipe it seemed like
+the sixth argument to PeekNamedPipe should return what I needed without
+using a buffer.  And, amazingly, it did, except that the problem still
+remained - a zero byte message still screwed things up.
+
+So, we now detect the case where there is zero bytes available as a
+message but there are bytes available in the pipe.  In that scenario,
+return the bytes available in the pipe rather than the message length of
+zero.  This could conceivably cause problems with pty pipe handling in
+this scenario but since the only way this scenario could possibly happen
+is when someone is writing zero bytes using WriteFile to a pty pipe, I'm
+ok with that.
+
 2012-05-14  cgf-000007
 
 <1.7.16>