Re: [Bug-readline] Line width not adjusted after window resizes

[Chet Ramey]

On 3/21/15 9:32 PM, Carlos Pita wrote:
> Maybe you will be interested in following this
> http://bugs.python.org/issue23735 as some people there consider the issue
> as a bug in readline.

Sure.  Here's the story from the top.

Prior to readline-6.3, readline could `steal' signals from the calling
application in the sense that readline's signal handler got a crack at
all signals in which readline was interested before the application did.
Now, that was usually ok, since readline handled signals immediately
upon receipt and resent the signal to the calling application.  It did
all this in a signal handler context.

It's dangerous to execute `unsafe' library functions and system calls from
a signal handler. The Posix standard has a (short) list of signal-safe
functions.  Before bash-4.3/readline-6.3, readline and bash did far too
much work in signal handlers.  The most you are supposed to do in a signal
handler is set variables, preferably of type sig_atomic_t, and nothing
else.  The biggest offenders are malloc and free, for two reasons:
applications often want to provide their own memory allocation atop
malloc and free, and using them from signal handlers can interfere; and
the glibc versions use internal locks extensively, and calling, say, free
from a signal handler can end up in a deadlock.

I made some progress up to bash-4.2/readline-6.2 in deferring `real' work
until readline wasn't in a signal handling context using the
RL_CHECK_SIGNALS() macro, but there were still a few places left that
handled the signal immediately.  One of those places was the callback
handling code; another was the SIGWINCH handling.

The SIGWINCH code signal handling functions eventually generated the same
sort of bug reports as other signals.  One representative report is

http://lists.gnu.org/archive/html/bug-bash/2011-02/msg00291.html

The fix was to make SIGWINCH handling the same as other signals: set a
flag and defer handling until no longer in a signal handling context.
This was necessary in both `direct' and callback modes.

The gdb folks reported most of the problems with the callback code handling
signals immediately instead of deferring handling until out of a signal
handler context; one such report is

http://lists.gnu.org/archive/html/bug-readline/2011-07/msg00010.html

So now the SIGWINCH and the callback code had to be changed to avoid
unsafe function calls from within a signal handler.

That very quickly uncovered a problem: the issue of readline stealing
the application's signals became much worse.

http://lists.gnu.org/archive/html/bug-readline/2011-07/msg00012.html

is the first explanation of that phenomenon.  If readline's signal
handlers are called when the application is active (e.g., between the
calls to rl_callback_handler_install and rl_callback_read_char), and all
they do is set a private flag the application doesn't know about, the
signals will effectively be ignored until the next time the application
calls into the readline callback interface and readline can check signals.
This is not acceptable in most contexts, including for SIGWINCH.

The fix for that is to make readline's signal handlers be active only
when readline is active and can check the flag the handlers set.

And so we reach where we are.  If a SIGWINCH arrives while readline is
not active, and the application using callback mode does not catch it and
tell readline about the updated screen dimensions (rl_set_screen_size()
exists for this purpose), readline will not know about the new size.

It seems like the issue is that people assume that the pre-readline-6.3
behavior was acceptable because they never encountered a problem, and that
any change must therefore be a bug.

Please feel free to add this message to the python issue tracker.

Chet
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU    address@hidden    http://cnswww.cns.cwru.edu/~chet/