Re: pending signal after rl_callback_read_char

[Chet Ramey]

On 9/20/22 12:05 PM, Chet Ramey wrote:
> On 9/16/22 10:25 AM, Tom de Vries wrote:
> > Hi,
> >
> > with gdb we've run into a PR ( 
> > https://sourceware.org/bugzilla/show_bug.cgi?id=27813 ) where the call to 
> > rl_callback_read_char returns with rl_pending_signal () != 0 after 
> > pressing ^C.
>
> Thanks for the report. I don't quite buy the analysis in comment 9
> (https://sourceware.org/bugzilla/show_bug.cgi?id=27813#c9).

OK, continuing.

Let's say it's the same (first) call to rl_callback_read_char(): the call
to readline_internal_char() has returned, the call to rl_dispatch has
output the ^G, and we're down in _rl_internal_char_cleanup when the SIGINT
arrives.

Since rl_done == 0, it calls rl_redisplay, and we're in the middle of that.
There's nothing in that function that will act on a SIGINT, so it returns,
and _rl_internal_char_cleanup returns, which causes readline_internal_char
to return.

And so we find ourselves back here again:


> So say _rl_internal_char_cleanup() returns 0 without the abort() you added.
> I assume it's been called by rl_callback_read_char() in this call:
>
>          eof = readline_internal_char ();
>
> The first thing rl_callback_read_char does after that is
> RL_CHECK_SIGNALS(). You'd think that would do the trick. If
> rl_callback_read_char is returning from some other path, I'd like to see
> it. It's not apparent from that trace.

I still have the same question about which code path is returning from
rl_callback_read_char and why the RL_CHECK_SIGNALS doesn't find that
_rl_caught_signal == SIGINT.

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.

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/