Re: pending signal after rl_callback_read_char

[Simon Marchi]

On 2022-09-20 15:54, Chet Ramey wrote:
> On 9/20/22 3:13 PM, Simon Marchi wrote:
>>
>>> It could be a timing issue: the signal arrives after rl_callback_read_char
>>> checks for it and before it returns, but there's not a lot it can do about
>>> that. That's why we have rl_check_signals() now.
>>
>> That's what I think, there's a window in rl_callback_read_char after the
>> last time rl_check_signals was called, but before the original (user's)
>> signal handlers are put back in place.  If the SIGINT arrives during
>> that window, it will go unnoticed until the next call to
>> rl_callback_read_char (or some other readline function).
> 
>     [...]
> 
>> I think that it could be fixed in readline by doing the following when
>> reinstalling the old signal handlers:
>>
>>   - block signals
>>   - call RL_CHECK_SIGNALS
>>   - restore old handlers
>>   - unblock signals
> 
> That's more of a change than I'm willing to make before readline-8.2 is
> released.

That's reasonable.

> In the meantime, you could look at rl_persistent_signal_handlers,
> which, in theory, should work on readline versions >= 7.0.

Ok, however GDB has its own signal handlers that it relies on, so I'm
not sure how it would work if readline's handlers were installed all the
time.

Just a note, earlier you said that GDB is using readline without any
callback and that it blocks into rl_callback_read_char, I don't think
that's true.  We have an event loop and only call into readline when
input is available.

So, I'm not entirely sure how things work when you are sitting at the
GDB prompt and press ^C.  Does readline get involved at all in that
case?  What are readline signals useful for?  I see we can also disable
readline's signal handling (set rl_catch_signals to 0), I'm wondering if
that would work for us.

Simon