mike@cimcor.UUCP (Michael Grenier) (11/23/87)
In article <1107@sugar.UUCP>, karl@sugar.UUCP (Karl Lehenbauer) writes: > Well, I pulled MicroEMACS 3.9e off of comp.sources.misc and gave them a > try under Microport Sys V/286 2.2. After changing the makefile to do a > > Anyway, emacs works just fine, but it totally eats CPU time (pretty > much all that's available), even when it's just sitting there waiting for > keys. Anybody know what's happening? I selected USG and Unix compiler, > terminal output as termcap; the rest are defaults. I thought I'd ask Hmmm... it does seem to be doing something strange. It grabs all the CPU time on my system as well (though at a low priority) in some sort of system call. What's really strange is that version 3.8i which I had installed patches for terminfo support consumes no time when idle. Perhaps the question is, when will Daniel Lawrence support System V Unix with terminfo instead/in addition to the older termcap. Actually, its looping at line 431 in termio.c polling stdin. I'm not a unix wizard so I don't understand why he special cased USG from the V7/BSD version at this point. -Mike {ihnp4, amdahl, rutgers}!meccts!cimcor!mike (Dan, I'll come up with patches if you want...Not that this is really the problem with the looping}
nwd@j.cc.purdue.edu (Daniel Lawrence) (11/24/87)
In article <422@cimcor.UUCP> mike@cimcor.UUCP (Michael Grenier) writes: >........... Perhaps the question is, when will Daniel Lawrence >support System V Unix with terminfo instead/in addition to the >older termcap. > Well, I will happily support it, if someone sends me a machine it will run on.... I can only put in what others send me right now, and can't even test it out. >(Dan, I'll come up with patches if you want...Not that this is really >the problem with the looping} Please do.... Daniel Lawrence (317) 742-5153 UUCP: {ihnp4!pur-ee!}j.cc.purdue.edu!nwd ARPA: nwd@j.cc.purdue.edu FIDO: 201/2 The Programmer's Room (317) 742-5533
larry@jc3b21.UUCP (11/25/87)
in article <422@cimcor.UUCP>, mike@cimcor.UUCP (Michael Grenier) says: > In article <1107@sugar.UUCP>, karl@sugar.UUCP (Karl Lehenbauer) writes: >> >> Anyway, emacs works just fine, but it totally eats CPU time (pretty >> much all that's available), even when it's just sitting there waiting for > > Hmmm... it does seem to be doing something strange. It grabs all the > CPU time on my system as well (though at a low priority) in some > sort of system call. What's really strange is that version 3.8i which What you are probably experiencing is trouble with the 'typeahead' code for System V. This is one of the reasons that I eliminated this code when I added the terminfo/termcap support for uemacs. It is an unfortunate situation that there is no call equivalent to the BSD 'how many chars are waiting' call. Anyway, the typeahead can be eliminated (its in tcap and termio) to speed up the process. Alternately if you install my diffs for termcap/terminfo it will go away automatically. I'm trying to find a good alternate for System V, but its not easy. BTW, I've run into a rather strange behaviour between uemacs on a 3b2/300 and on a XENIX 286 machine. Under XENIX, you can edit a 100K-500K file with no trouble at all. Does take a while to read, but what doesn't? On the 3b2, uemacs just hangs reading the file forever (or at least more than 30 minutes for a 100K file. Thats all I was willing to waste). Anyone have any ideas? -l -- +--------------------------------------+-- St. Petersburg Junior College --+ | Lawrence F. Strickland | P.O. Box 13489 | | ...gatech!codas!usfvax2!jc3b21!larry | St. Petersburg, FL 33733 | +-(or) ...gatech!usfvax2!jc3b21!larry -+-- Phone: +1 813 341 4705 ---------+
mumble%karl@tut.cis.ohio-state.edu.UUCP (11/25/87)
This is a bug for which Bill Davidsen (davidsen@steinmetz) posted a fix a week or so before 3.9e itself was posted. Here's the report as he distributed it to comp.emacs on 9 Nov. Note that there are 3 fixes here. The last is the one for SysV. From: davidsen@steinmetz.steinmetz.UUCP (William E. Davidsen Jr) Newsgroups: comp.emacs Subject: Fixes and enhancements to MicroEMACS 3.9e Date: 9 Nov 87 21:53:40 GMT Organization: GE Corp. R & D, Schenectady,NY A few small fixes to the new version 3.9e, shortly to be posted to the net somewhere. I will post my first set of fixes to the documentation in a few days. If you run a SysII/SysV system be sure to grab the fix in termio! This posting has one VMS enhancement, and several small changes. I have only run it on a few SysV machines, and only a few hours total. Looks *really* good. -- Reason for change: Addition of this change allows the emacs.rc file to be in the login directory rather than the current directory. Could also be "sys$login:[bin]" or something like that. Changes to epath.h: 70a71 > "sys$login:", Reason for change: When the VT100 option is selected there is a missing "{". Rather than put it in both places, which messes up my formatter, I placed it on a line by itself. Second change allows RETURN to be a quoted character in search or replace strings without being turned into a newline. This makes adding or deleting returns from files much easier. Changes to input.c: 357c357 < if (c == metac) { --- > if (c == metac) 358a359 > { 413c414 < if (c == (CTRL | 0x4d)) --- > if (c == (CTRL | 0x4d) && !quotef) Reason for change: When the USG (SysIII/V) option is selected, stdin is placed in polling mode without setting the flag to indicate that this has been done. This causes all input to be done in polling mode, making CPU time = the clock time. While this is not obvious on a single user system, on a large system it is not acceptable. This change sets the polling flag when polling mode is used. There was also some code to loop on input, caused by the polling flag error. I removed it. Changes to termio.c: 431,432c431 < while (read(0, &kbdq, 1) != 1) < ; --- > read(0, &kbdq, 1); 489a489 > kbdpoll = TRUE; -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me -=- Karl
davidsen@steinmetz.steinmetz.UUCP (William E. Davidsen Jr) (11/26/87)
I posted this once before and mailed a copy to the author. This is the fix for the polling in SysV as well as some other bugs. Each fix is carefully documented describing what it fixes. ---------------------------------------------------------------- Reason for change: Addition of this change allows the emacs.rc file to be in the login directory rather than the current directory. Could also be "sys$login:[bin]" or something like that. Changes to epath.h: 70a71 > "sys$login:", Reason for change: When the VT100 option is selected there is a missing "{". Rather than put it in both places, which messes up my formatter, I placed it on a line by itself. Second change allows RETURN to be a quoted character in search or replace strings without being turned into a newline. This makes adding or deleting returns from files much easier. Changes to input.c: 357c357 < if (c == metac) { --- > if (c == metac) 358a359 > { 413c414 < if (c == (CTRL | 0x4d)) --- > if (c == (CTRL | 0x4d) && !quotef) Reason for change: When the USG (SysIII/V) option is selected, stdin is placed in polling mode without setting the flag to indicate that this has been done. This causes all input to be done in polling mode, making CPU time = the clock time. While this is not obvious on a single user system, on a large system it is not acceptable. This change sets the polling flag when polling mode is used. There was also some code to loop on input, caused by the polling flag error. I removed it. Changes to termio.c: 431,432c431 < while (read(0, &kbdq, 1) != 1) < ; --- > read(0, &kbdq, 1); 489a489 > kbdpoll = TRUE; -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
manes@dasys1.UUCP (Steve Manes) (11/26/87)
In article <422@cimcor.UUCP> mike@cimcor.UUCP (Michael Grenier) writes: >Hmmm... it does seem to be doing something strange. It grabs all the >CPU time on my system as well (though at a low priority) in some >sort of system call. What's really strange is that version 3.8i which >I had installed patches for terminfo support consumes no time >when idle. I noticed this problem mostly when running multiple MicroEMACS processes and response time for both dropped significantly. I haven't looked at the termio.c that closely (it's archived now) but it appeared from the symptoms that 3.9 termio.c uses raw input, which isn't very efficient for UNIX. All I did was link in the older 3.8 termio.o and it works fine. -- +----------------------------------------------------------------------- + Steve Manes Roxy Recorders, Inc. NYC + decvax!philabs!cmcl2!hombre!magpie!manes Magpie BBS: 212-420-0527 + uunet!iuvax!bsu-cs!zoo-hq!magpie!manes 300/1200/2400
allbery@ncoast.UUCP (11/29/87)
As quoted from <422@cimcor.UUCP> by mike@cimcor.UUCP (Michael Grenier): +--------------- | In article <1107@sugar.UUCP>, karl@sugar.UUCP (Karl Lehenbauer) writes: | > Anyway, emacs works just fine, but it totally eats CPU time (pretty | > much all that's available), even when it's just sitting there waiting for | > keys. Anybody know what's happening? I selected USG and Unix compiler, | > terminal output as termcap; the rest are defaults. I thought I'd ask | | Hmmm... it does seem to be doing something strange. It grabs all the | CPU time on my system as well (though at a low priority) in some | sort of system call. What's really strange is that version 3.8i which | I had installed patches for terminfo support consumes no time | when idle. Perhaps the question is, when will Daniel Lawrence | support System V Unix with terminfo instead/in addition to the | older termcap. | | Actually, its looping at line 431 in termio.c polling stdin. | I'm not a unix wizard so I don't understand why he special cased | USG from the V7/BSD version at this point. +--------------- Don't patch it blindly or you'll lose functionality. The reason it loops is that System V has a "non-blocking read", which allows the program to continue if nothing has been typed. At the least, I'd hazard a guess that it is used to interrupt a refresh when there is pending input. BSD has a better way (two, in fact): select() has the ability to check for input with an optional timeout, and ioctl(fd, FIONREAD, &c) places in the variable "c" the number of pending unread characters on file descriptor "fd". Xenix also has an alternative: rdchk(fd) is like BSD FIONREAD, but it returns its result rather than storing it in a variable, and it's designed (or *was* designed) to have an especially low overhead. V7 doesn't have *any* way of checking for input. As for termcap/terminfo: some people don't like terminfo. And even if they *do* use it, terminfo can be used in "termcap compatible" mode. -- Brandon S. Allbery necntc!ncoast!allbery@harvard.harvard.edu {hoptoad,harvard!necntc,cbosgd,sun!mandrill!hal,uunet!hnsurg3}!ncoast!allbery Moderator of comp.sources.misc
rupley@arizona.UUCP (11/30/87)
in article <205@jc3b21.UUCP>, larry@jc3b21.UUCP (Lawrence F. Strickland) says: > in article <422@cimcor.UUCP>, mike@cimcor.UUCP (Michael Grenier) says: >> In article <1107@sugar.UUCP>, karl@sugar.UUCP (Karl Lehenbauer) writes: >>> >>> Anyway, emacs works just fine, but it totally eats CPU time (pretty >>> much all that's available), even when it's just sitting there waiting for >> >> Hmmm... it does seem to be doing something strange. It grabs all the >> CPU time on my system as well (though at a low priority) in some >> sort of system call. What's really strange is that version 3.8i which > <stuff on the typeahead fix deleted> > >BTW, I've run into a rather strange behaviour between uemacs on a 3b2/300 >and on a XENIX 286 machine. Under XENIX, you can edit a 100K-500K file with >no trouble at all. Does take a while to read, but what doesn't? On the >3b2, uemacs just hangs reading the file forever (or at least more than 30 >minutes for a 100K file. Thats all I was willing to waste). Anyone have >any ideas? This is probably not a Microemacs problem. It may be a sysV problem. Under Microport sysV/AT, repeated calls to malloc allocate nicely and quickly, up to a limit of several hundred kbytes. Then a dramatic slowdown, associated with swapping. There appears to be no easy fix. It may be a kernel problem. It is not due to insufficient memory or swap space. To see if something like this is happening on the 3b2, use: timex -s emacs largefilename and hit ^X^C to exit as soon as the file is read. The timex output will allow you to identify what parts of the system are being exercised normally and in the slow-allocation regime. Check for an increase in swapping activity, comparing the reads of small files and large files (the latter large enough to be above the threshhold). I would be interested in knowing if sysV on a 3b2 shows this. John Rupley uucp: ..{ihnp4 | hao!noao}!arizona!rupley!local internet: rupley!local@megaron.arizona.edu telex: 9103508679(JARJAR) (H) 30 Calle Belleza, Tucson AZ 85716 - (602) 325-4533 (O) Dept. Biochemistry, Univ. Arizona, Tucson AZ 85721 - (602) 621-3929
davidsen@steinmetz.steinmetz.UUCP (William E. Davidsen Jr) (11/30/87)
In article <6295@ncoast.UUCP> allbery@ncoast.UUCP (Brandon Allbery) writes: >As quoted from <422@cimcor.UUCP> by mike@cimcor.UUCP (Michael Grenier): >+--------------- >| In article <1107@sugar.UUCP>, karl@sugar.UUCP (Karl Lehenbauer) writes: >| > Anyway, emacs works just fine, but it totally eats CPU time (pretty >| > much all that's available), even when it's just sitting there waiting for > >Don't patch it blindly or you'll lose functionality. The reason it loops >is that System V has a "non-blocking read", which allows the program to >continue if nothing has been typed. At the least, I'd hazard a guess that >it is used to interrupt a refresh when there is pending input. I posted a fix for this the day after 3.9e was released, and someone just posted the fix again. The program sets "polling mode" while updating, and "blocking mode" when reading the keys. The loop was put in because the poll didn't return a character. If you set the "polling mode" flag where the ioctl changes to polling (later in the same routine) it works fine. I reported this in 3.9 but just used 3.8i for that module. After fixing the flag, you can take the while loop out and just read the keyboard with a normal read. I posted the fixes, but not the logic, hope this permanently fixes the problem. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me