Carlos Pita added the comment: Chet again:
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. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue23735> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com