On Wed, Dec 13, 2023 at 01:33:59AM +0100, наб wrote:
> On Tue, Dec 12, 2023 at 05:55:38PM -0500, Thomas Dickey wrote:
> > On Tue, Dec 12, 2023 at 11:09:13PM +0100, наб wrote:
> > > urlview 1c-1 whose xterm was killed but which didn't die consumes 100% 
> > > CPU.
> > > The event loop is for(;;) switch(getch()) ... and ignores -1
> > If it's going to ignore the error return (while at the same time
> > manipulating the time delays with mousemask), then this is expected
> > (mis)behavior.
> Sure.
> 
> Still, it doesn't set errno to EINTR,

...and the manual page does not say it would do that.

It lists three possible causes for ERR being returned,
and on the third it mentions that errno will be set:

       returns ERR if the window pointer is null, or if its timeout
       expires without having any data, or if the execution was interrupted by
       a signal (errno will be set to EINTR).

It could be reformatted like this without changing its meaning:

       returns ERR
       
       * if the window pointer is null, or

       * if its timeout expires without having any data, or

       * if the execution was interrupted by a signal (errno will be set to
         EINTR).

though doing that for every 2-3 line sentence will make the page less readable.

(errno isn't set for a null window pointer either)

> and instant empty reads you get from a hung-up teletype
> definitely aren't exceeding the timeout.

https://git.sr.ht/~nabijaczleweli/urlview-ng/tree/1c/item/urlview.c#L441

mouseinterval(0) tells it to not wait for mouse events, and results in
a zero-delay in check_mouse_activity:

https://github.com/ThomasDickey/ncurses-snapshots/blob/b5a2b7c720102b187e6d1099f36ed2643fea4934/ncurses/base/lib_getch.c#L152

That looks like someone's attempting to make the wheel mouse work at
infinite velocity -- and might be the reason for ignoring errors -- and
might be the reason for the 100% CPU.

I'd have used a 5msec delay (or 1msec for "modern" computers :-)

If ncurses is actually reading from a closed file descriptor, the manpage
for read(2) suggests that errno may be set to EBADF -- but since you say
errno is _not_ being set, then there's nothing to alert ncurses to the
problem -- the timeout expired.  (You may get more insight using strace).

-- 
Thomas E. Dickey <dic...@invisible-island.net>
https://invisible-island.net

Attachment: signature.asc
Description: PGP signature

Reply via email to