Re: [Bug-readline] documentation of signal handling

[Chet Ramey]

On 4/25/16 2:59 PM, address@hidden wrote:
> Dear Readline people (and Chet Ramey),
> 
> I'm trying to help fix some bugs in the R interpreter, involving
> signals not being received by GNU Readline.
> 
> R currently has problems which stem from ignoring SIGWINCH
> <https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16604>, and
> failing to correctly reset the Readline state upon receiving SIGINT
> <https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16603>.

I believe that this is correct, in that these signals arrive when
readline is not reading and processing a character, and therefore
does not have its signal handlers installed.

> I understand from reading about a similar bug in Python
> <https://bugs.python.org/issue23735> that the problem may stem from
> signal handling changes made in Readline 6.3.
> 
> According to the Python bug (which quotes Chet), the solution is for
> the application itself to trap SIGWINCH, and then set a flag to call
> "rl_resize_terminal()" before the next "select()".

Yes, something like

static void
sighandler (int sig)
{
  rl_resize_terminal ();
}

(Technically this is unsafe; you should, as you note, set a flag and call
rl_resize_terminal from your program's main loop if that flag is set.
But you have the idea.)

> 
> However, the need to do this is apparently not yet noted in the
> Readline documentation, for instance the "Alternate interface example"
> <http://cnswww.cns.cwru.edu/php/chet/readline/readline.html#SEC43>
> seems to lack the extra code for SIGWINCH (and, presumably, SIGINT).

Thanks for the reminder.  The example needs to be updated for SIGWINCH,
but simply exits -- as most programs do -- on SIGINT.  If you want to
handle SIGINT, you're already doing it: you already have a functioning
signal handler.  There are a couple of things you need to add to it to
make it clean up the readline state if you're not exiting:

rl_free_line_state ();          /* clean up the line buffer */
rl_callback_sigcleanup ();      /* dispose of internal readline state */

Since readline isn't active, you don't need to call rl_cleanup_after_signal().

That second function is new in readline-7.0; it fixes a bug in previous
readline versions.

> Delving a bit deeper, I'm wondering why it was necessary for Readline
> to make application writers do all this extra work. For instance, why
> not go back to installing signal handlers (via "rl_set_signals()") in
> "rl_callback_handler_install()", and extend the callback interface
> with a function - e.g. "rl_check_for_signal()" - that queries
> _rl_caught_signal to see if a signal is pending? 

This is an interesting approach, but it's years too late, and would not
have satisfied the requirements being presented at the time: the
applications already had existing signal handling functions they needed
to have called when signals arrived.

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/