RE: PATCH: ptyread eating CPU on Cygwin

["Andrej Borsenkow" <Andrej.Borsenkow@xxxxxxxxxxxxxx>]

>
> I'm not Sven, but HAVE_SELECT does not imply having FD_ZERO or an fd_set
> typedef.
>
> On the other hand, I've just noticed that other code assumes in several
> places that it does imply those things, so it's probably OK.
>

Yes, it was just copy'n'paste.

> However, using a NULL timeout structure in the select() call has turned a
> non-blocking read into a fully blocking one.  If you're going to do that,
> you might as well throw out the select() call and just set the descriptor
> back to blocking state before calling read().  I suspect there's a good
> reason it was a non-blocking read in the first place, though.
>

Erm. You are right, of course.

Non-blocking read made sense in initial implemetation, because it was the
condition to exit read loop (without pattern matching) - 9390:

+    do {
+	while ((ret = read(cmd->fd, buf + used, 1)) == 1) {
+	    if (++used == blen) {
+		buf = hrealloc(buf, blen, blen << 1);
+		blen <<= 1;
+	    }
+	}
+	buf[used] = '\0';
+    } while (prog && !pattry(prog, buf));

Currently zsh tries to always read the whole input (until EOF) Actually, in
pattern-matching mode it even completely ignores EOF. That makes absolutely no
functional difference between blocking and non-blocking mode but makes
performance in non-blocking mode terrible.

As it stands now, we really can just use blocking read.

-andrej