--- a/lib-src/ChangeLog	Mon Dec 06 23:27:32 2004 +0000
+++ b/lib-src/ChangeLog	Tue Dec 07 00:20:51 2004 +0000
@@ -1,3 +1,8 @@
+2004-12-06  Ben Wing  <ben@xemacs.org>
+
+	* i.c (pump):
+	Undo change of 2003-03-06.  It causes truncation of output at the end.
+
 2004-12-06  Ben Wing  <ben@xemacs.org>
 
 	* gnuclient.c:

--- a/lib-src/i.c	Mon Dec 06 23:27:32 2004 +0000
+++ b/lib-src/i.c	Tue Dec 07 00:20:51 2004 +0000
@@ -67,18 +67,30 @@
   BYTE buffer [256];
   DWORD really_read, unused;
 
-  /* The docs for ReadFile claim:
+  /* I said:
+  
+  [[ The docs for ReadFile claim:
 
   The ReadFile function returns when one of the following is true: a write
   operation completes on the write end of the pipe, the number of bytes
   requested has been read, or an error occurs.
 
   But this is just not true.  ReadFile never seems to block, and unless we
-  Sleep(), we will chew up all the CPU time. --ben
-  */
+  Sleep(), we will chew up all the CPU time. --ben ]]
+
+  But in fact
+
+  [a] this does not appear to be the case any more [maybe a temporary
+      bug in some versions of Win2000?]
+  [b] it causes data lossage. [#### Why should this be?  Seems extremely
+      fishy.  I tried commenting out the calls to close the standard
+      handles at the bottom of the program, but it made no difference.
+      Would we need some kind of additional handshaking?  If we get
+      data loss with the sleep, then we are a race condition waiting
+      to happen. */
   while (ReadFile (pi->source, buffer, sizeof (buffer), &really_read, NULL) &&
 	 WriteFile (pi->drain, buffer, really_read, &unused, NULL))
-    Sleep (100);
+    /* Sleep (100) */ ;
 
   return 0;
 }