[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-readline] documentation of signal handling

From: Chet Ramey
Subject: Re: [Bug-readline] documentation of signal handling
Date: Tue, 26 Apr 2016 10:14:55 -0400
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.7.2

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.

``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/

reply via email to

[Prev in Thread] Current Thread [Next in Thread]