Re: pending signal after rl_callback_read_char

[Simon Marchi]

On 2022-09-21 10:04, Chet Ramey wrote:
> On 9/20/22 4:17 PM, Simon Marchi wrote:
> 
>>> In the meantime, you could look at rl_persistent_signal_handlers,
>>> which, in theory, should work on readline versions >= 7.0.

FWIW, I tested this, and I don't think it helps.  This only causes
readline's signal handlers to stay between rl_callback_read_char calls,
for a single line, but the critical window described earlier still
exists.  If a SIGINT arrives within that window, GDB's SIGINT handler
will still only be called on the next rl_callback_read_char call, which
is only when new input is available (when the user presses another key).

>> 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.
> 
> "All the time" means from the time readline prints a prompt until it
> executes rl_accept_line or otherwise sets rl_done, presumably over a series
> of calls to rl_callback_read_char(). It's the equivalent of having readline's 
> signal handlers installed for the duration of a call to
> readline().
> 
> The default is to have the signal handlers installed only for the duration
> of a call to rl_callback_read_char().

Ok.

> Readline's signal handler calls any application-installed handler (well,
> it resets the signal dispositions and resends the signal). That's how gdb's
> SIGINT handler gets called when readline's signal handlers are installed.

Ok, thanks for the info.

>>
>> 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.
> 
> You haven't executed a readline command that would cause a function pointer 
> to be assigned to _rl_callback_func (private and internal). That's another 
> code path that executes _rl_internal_char_cleanup() (there are several).

Ok.

>> 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? 
> 
> If readline is in the middle of a call to rl_callback_read_char, then yes.
> If not, then no.

Ok...  I thought GDB would need to tell readline to flush the current
line somehow.  When the user has typed some text and not pressed enter
yet, the current line is saved in readline, right?

>> What are readline signals useful for? 
> 
> Readline changes the terminal settings and other user state, and allocates
> per-call memory and other resources, and has to catch signals so it can
> clean that up.
> 
>> 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.
> 
> Sure, if you want to do all that work for yourself.

Difficult to say without knowing what "that work" consists of exactly
(haven't had time to dig in that).

Thanks,

Simon