* ptyread eating CPU on Cygwin
@ 2000-10-17 16:56 Andrej Borsenkow
2000-10-18 9:04 ` Peter Stephenson
0 siblings, 1 reply; 5+ messages in thread
From: Andrej Borsenkow @ 2000-10-17 16:56 UTC (permalink / raw)
To: ZSH workers mailing list
I could finally run (almost) all Zsh tests under lasy Cygwin snapshot.
Unfortunately, doing it I found, that reading from pty currently takes about
98% CPU time :-( (I wonder, why we do not notice it on Unix). That is well
seen running completion tests.
Peter, you that select does not work under Cygwin (read_poll). I asked on
Cygwin list, but there are no known problems and many applications do use
select.
What specific problems did you have?
-andrej
Have a nice DOS!
B >>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: ptyread eating CPU on Cygwin
2000-10-17 16:56 ptyread eating CPU on Cygwin Andrej Borsenkow
@ 2000-10-18 9:04 ` Peter Stephenson
2000-10-18 11:30 ` PATCH: " Andrej Borsenkow
0 siblings, 1 reply; 5+ messages in thread
From: Peter Stephenson @ 2000-10-18 9:04 UTC (permalink / raw)
To: Zsh hackers list
> Peter, you that select does not work under Cygwin (read_poll). I asked on
> Cygwin list, but there are no known problems and many applications do use
> select.
The problem I was having was with putting the terminal temporarily into raw
mode without the full majesty of zle and setting a timeout there (in
bin_read()). select is working fine in the main terminal code. I didn't
have the week necessary to resolve all the possible ways of setting
timeouts, so I gave up. I expect it can be done.
--
Peter Stephenson <pws@csr.com> Software Engineer
Cambridge Silicon Radio, Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK Tel: +44 (0)1223 392070
^ permalink raw reply [flat|nested] 5+ messages in thread
* PATCH: ptyread eating CPU on Cygwin
2000-10-18 9:04 ` Peter Stephenson
@ 2000-10-18 11:30 ` Andrej Borsenkow
2000-10-18 15:55 ` Bart Schaefer
0 siblings, 1 reply; 5+ messages in thread
From: Andrej Borsenkow @ 2000-10-18 11:30 UTC (permalink / raw)
To: Zsh hackers list
[-- Attachment #1: Type: text/plain, Size: 682 bytes --]
>
> The problem I was having was with putting the terminal temporarily into raw
> mode without the full majesty of zle and setting a timeout there (in
> bin_read()). select is working fine in the main terminal code. I didn't
> have the week necessary to resolve all the possible ways of setting
> timeouts, so I gave up. I expect it can be done.
>
O.K., this is very simple patch that makes ptyread use select. Sven, could you
look at conditions there? It should be O.K. (blocking select can return either
positive value or -1 if interrupted, in which case we simply exit read loop).
With this patch 'make check' has acceptable CPU load.
Attached due to line length.
-andrej
[-- Attachment #2: zsh-zpty.diff --]
[-- Type: application/octet-stream, Size: 986 bytes --]
Index: Src/Modules/zpty.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Modules/zpty.c,v
retrieving revision 1.11
diff -u -r1.11 zpty.c
--- Src/Modules/zpty.c 2000/06/27 14:25:05 1.11
+++ Src/Modules/zpty.c 2000/10/18 11:26:20
@@ -446,6 +446,9 @@
int blen = 256, used = 0, ret = 1;
char *buf = (char *) zhalloc(blen + 1);
Patprog prog = NULL;
+#ifdef HAVE_SELECT
+ fd_set foofd;
+#endif
if (*args && args[1]) {
char *p;
@@ -468,7 +471,16 @@
if (cmd->fin)
break;
}
- if ((ret = read(cmd->fd, buf + used, 1)) == 1) {
+#ifdef HAVE_SELECT
+ FD_ZERO(&foofd);
+ FD_SET(cmd->fd, &foofd);
+#endif
+ if (
+#ifdef HAVE_SELECT
+ (ret = select(cmd->fd+1, (SELECT_ARG_2_T) &foofd, NULL, NULL, NULL) > 0) &&
+#endif
+
+ (ret = read(cmd->fd, buf + used, 1)) == 1) {
if (++used == blen) {
buf = hrealloc(buf, blen, blen << 1);
blen <<= 1;
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: PATCH: ptyread eating CPU on Cygwin
2000-10-18 11:30 ` PATCH: " Andrej Borsenkow
@ 2000-10-18 15:55 ` Bart Schaefer
2000-10-18 16:44 ` Andrej Borsenkow
0 siblings, 1 reply; 5+ messages in thread
From: Bart Schaefer @ 2000-10-18 15:55 UTC (permalink / raw)
To: Andrej Borsenkow, Zsh hackers list
On Oct 18, 3:30pm, Andrej Borsenkow wrote:
}
} O.K., this is very simple patch that makes ptyread use select. Sven,
} could you look at conditions there?
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.
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.
--
Bart Schaefer Brass Lantern Enterprises
http://www.well.com/user/barts http://www.brasslantern.com
Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net
^ permalink raw reply [flat|nested] 5+ messages in thread
* RE: PATCH: ptyread eating CPU on Cygwin
2000-10-18 15:55 ` Bart Schaefer
@ 2000-10-18 16:44 ` Andrej Borsenkow
0 siblings, 0 replies; 5+ messages in thread
From: Andrej Borsenkow @ 2000-10-18 16:44 UTC (permalink / raw)
To: Zsh hackers list
>
> 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
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2000-10-18 16:44 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-10-17 16:56 ptyread eating CPU on Cygwin Andrej Borsenkow
2000-10-18 9:04 ` Peter Stephenson
2000-10-18 11:30 ` PATCH: " Andrej Borsenkow
2000-10-18 15:55 ` Bart Schaefer
2000-10-18 16:44 ` Andrej Borsenkow
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).