Re: callback api, isearch, signals issue

[Andrew Burgess]

Chet Ramey <chet.ramey@case.edu> writes:

> On 1/6/23 10:07 AM, Andrew Burgess wrote:
>> Hi,
>> 
>> While working on GDB, which uses the callback API, I've run into some
>> issues relating to reverse isearch and signal handling.
>> 
>> At the end of this email is a small example program that uses the
>> callback API.  This is a modified version of the example program that
>> is included in the readline manual.
>> 
>> The issue I have relies on a SIGINT arriving at just the wrong time.
>> To reproduce this the test program uses rl_getc_function to setup a
>> wrapper function (my_getc) that calls rl_getc.  After a couple of
>> times calling my_getc, a SIGINT is sent to the process using kill().
>
> Two questions: what does gdb do when it gets the SIGINT? Readline sends it
> back to the calling application. I assume it just sets a flag? And does
> gdb set rl_signal_event_hook?

So, for SIGINT handling, I tried to kind-of model what GDB does in the
demo program.  [Any inaccuracies between actual GDB and my representation
of it here are entirely my own fault.]  But your guess is correct, GDB
sets a flag and writes a single byte to a pipe file descriptor.

When we return to GDB's main event loop, the pending read wakes our
select, we then call the relevant sigint event handler.  This then
throws a C++ exception which is caught further up the stack, and we then
redisplay the prompt using the rl_callback_handler_remove and
rl_callback_handler_install calls that you can see in the demo program.

The demo program skips the whole C++ exception part, but I think is an
otherwise accurate representation of what GDB is doing.

A grep on the GDB source tree indicates we don't set
rl_signal_event_hook anywhere.  I'll take a look now at the role that
plays in this process and see if it will help at all, but I'd also
welcome any insights you have.

Thanks,
Andrew