[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: lynx-dev Connecting to... + press any arror key -> CPU problem

From: Klaus Weide
Subject: Re: lynx-dev Connecting to... + press any arror key -> CPU problem
Date: Thu, 20 Apr 2000 09:38:43 -0500 (CDT)

On Thu, 20 Apr 2000, Frederic L . W . Meunier wrote:

> When you connect to a site and Lynx stays at the Connecting
> to phase for a time (slow modem or site etc),

Not at the "Making ... connection to ..." stage, only at the
"Looking up ..." stage.  (If you have this often - and repeatedly
with the same site -, you should probably run a caching nameserver

> if you press any
> arrow key (maybe others too, didn't checked) and maintain it
> pressed you'll see that your CPU is being eated. OK, why the hell
> you should press any arrow key while connecting? I don't know, but
> I did sometimes and got this.
> Is this a Lynx problem.

This should only appear if you have configured --enable-nsl-fork.
(And last I checked, that still wasn't the default.)
This seems to be an interaction of the logic in the NSL_FORK code
(which has to check keyboard input for 'z') with stuff Tom added
in HTCheckForInterrupt() described thusly:
     * Avoid checking interrupts more than one per second, since it is a slow
     * and expensive operation - TD
(Note the comment doesn't match reality, it's 0.1 seconds if

HTCheckForInterrupt returns immediately if not enough time has passed
since the last check, as a result LYGetHostByName busy-loops (because
the next select() will return immediately, HTCheckForInterrupt will then
be called immediately again, and so on.)

> Can you reproduce it on your system? 

Yes.  Linux, with both ncurses and slang (under the conditions mentioned).

Try either of the following (both untested), I'd expect the CPU
consumption to go down drastically:

a) in LYUtils.c, in function
       PRIVATE int DontCheck NOARGS
insert a line
           return FALSE;

b) in HTTCP.c, in function
       PUBLIC struct hostent * LYGetHostByName ARGS1
   remove or comment out these lines:
                if (kbd_fd != INVSOC) {
                    FD_SET(kbd_fd, &readfds);

In any case, this is a minor problem (but still unnecessary).


reply via email to

[Prev in Thread] Current Thread [Next in Thread]