On 11/14/2012 09:33 AM, Eli Zaretskii wrote:

> In several places, it actually changes the code involved
> in dealing with the related issues.  Here's one example:

As far as I know, that is the only example involving O_NONBLOCK.

> Here, the code that was left is identical to the one used by platforms
> with O_NONBLOCK, but the code used by platforms with O_NDELAY was
> different in non-trivial ways.

Do those differences matter for Microsoft platforms?  If so, it's
simple to keep them just for DOS_NT, with the following further change:

=== modified file 'src/process.c'
--- src/process.c	2012-11-14 07:26:25 +0000
+++ src/process.c	2012-11-15 06:19:46 +0000
@@ -4797,6 +4797,14 @@
 #endif
 	      else if (nread == -1 && errno == EAGAIN)
 		;
+#ifdef DOS_NT
+	      /* Note that we cannot distinguish between no input
+		 available now and a closed pipe.
+		 With luck, a closed pipe will be accompanied by
+		 subprocess termination and SIGCHLD.  */
+	      else if (nread == 0 && !NETCONN_P (proc) && !SERIALCONN_P (proc))
+		;
+#endif
 #ifdef HAVE_PTYS
 	      /* On some OSs with ptys, when the process on one end of
 		 a pty exits, the other end gets an error reading with


> Another potential problem is that the Windows emulation of fcntl only
> works for sockets, whereas O_NONBLOCK is now used in other system
> calls, like in emacs_open etc.

emacs_open is the only other system call where it's used, and there it's
used only in code that is "#ifndef DOS_NT", so it should be OK.

> This patch also modifies code unrelated to O_NONBLOCK, like this one:

That's OK, as this patch is about all symbols defined by fcntl.h
in POSIX.1-1988, not just about O_NONBLOCK.

> Failing that, Someone(TM) will have to do the footwork of making
> sure these changes don't break non-Posix platforms.

The only non-POSIX platform are the Microsoft ones, right?
And if the above analysis is right, we should be OK.

Attached is a revised patch, relative to trunk bzr 110904,
and with the above extra change.