[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Is there any notimeout-nodelay interaction?
From: |
Thomas Dickey |
Subject: |
Re: Is there any notimeout-nodelay interaction? |
Date: |
Thu, 9 Jun 2016 18:53:11 -0400 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
On Thu, Jun 09, 2016 at 08:55:21PM +0200, CLEX wrote:
> Dear ncurses maintainers,
>
> I'm writing to you because a code that worked fine for about a
> decade recently broke down and I am unable to find the reason for
> it. It might be a bug in the ncursesw library or something that I
> have overlooked. Could you please kindly take a look?
>
> The initialization basically looks like this:
>
> initscr();
> raw();
> nonl();
> noecho();
> keypad(stdscr,TRUE);
> notimeout(stdscr,TRUE);
>
> and the input routine uses get_wch(). It is a blocking read.
>
> Few weeks ago users who installed a new version of Ubuntu Linux have
> reported problems. I have found out that get_wch() started to behave
> as non-blocking read and was immediately returning ERR value meaning
> no key.
>
> Commenting out the notimeout() call fixed the problem.
I recall responding to a bug report (it would be nice if this discussion
referenced it, if it's the same one).
> However, according to the man page on my system, notimeout()
> controls escape sequence interpretation. The function changing the
> get_wch()'s behaviour from blocking to non-blocking is a different
> one. It's the nodelay() function and that one was not called.
>
> In my understanding, calling notimeout() should not have the
> described effect, shouldn't it?
The change was here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=805618
and the manpage says:
The nodelay option causes getch to be a non-blocking call. If no input
is ready, getch returns ERR. If disabled (bf is FALSE), getch waits
until a key is pressed.
While interpreting an input escape sequence, wgetch sets a timer while
waiting for the next character. If notimeout(win, TRUE) is called,
then wgetch does not set a timer. The purpose of the timeout is to
differentiate between sequences received from a function key and those
typed by a user.
What I noticed when investigating this, was that the notimeout value was
copied to a couple of places - but never tested. Here's how it is used
now:
base/lib_getch.c:493: if (win->_notimeout || (win->_delay >= 0) ||
(sp->_cbreak > 1)) {
base/lib_getch.c:500: else if (win->_notimeout)
base/lib_screen.c:127: DATA(_notimeout, pBOOL),
base/lib_screen.c:566: nwin->_notimeout = tmp._notimeout;
base/lib_window.c:221: nwin->_notimeout = win->_notimeout;
tinfo/lib_options.c:127: win->_notimeout = f;
so... possibly the fix wasn't the best one (there may be a more suitable
way to apply notimeout). I'll look into that.
--
Thomas E. Dickey <address@hidden>
http://invisible-island.net
ftp://invisible-island.net
signature.asc
Description: Digital signature