Re: callback api, isearch, signals issue

[Andrew Burgess]

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

> On 1/11/23 6:21 AM, Andrew Burgess wrote:
>
>> I'm afraid that I didn't really understand this explanation.
>
> OK, look at the fix I pushed yesterday.

Thanks, I hadn't seen you'd pushed something related to this.  I removed
the use of rl_signal_event_hook from my demo program (GDB doesn't use
this anyway), and now everything works as expected.

Thanks for the fast fix, and your patience explaining things too me.

Thanks,
Andrew



>
>> I tried setting up the event handler in the demo application (that I
>> sent in the first email of this thread), and I don't believe that the
>> callback is ever invoked before readline crashes in the example I gave.
>
> It's not; it informs the fix. The issue is that the SIGINT arrives before
> rl_getc is called, so the question is how to handle it in a way that's
> compatible with signals that arrive during select/pselect/read.
>
> The event handler should be called for those `pending' signals as well, and
> is with the fix I pushed. In addition, there should be some default
> readline behavior that prevents crashes if the application doesn't do
> anything.
>
>> You talk about an expectation mismatch between readline and the
>> application using readline, except, in the example I gave, it doesn't
>> seem that the application is involved at all, this appears to be
>> entirely an internal readline issue; the SIGINT arrives, readline
>> cancels the isearch, then readline calls rl_isearch_dispatch.
>
> It is a readline issue -- the question is where and how to fix it. For
> instance, should the application get to decide whether or not a SIGINT
> cancels the incremental search (or whatever else it happened to be doing),
> or should readline make that decision? The fix I pushed leaves it up to the
> application if it's installed a signal event handler. The only reasonable
> behavior is to longmp out, but to where?
>
> So the remaining question is whether or not this new readline behavior of
> calling _rl_abort_internal on SIGINT in callback mode when readline is in
> a search or collecting a numeric argument should be unconditional or
> performed only when the application hasn't set a signal event handler.
>
>> I'm wondering if _rl_isearch_dispatch should be extended to check if the
>> isearch has already been aborted? 
>
> No.
>
> -- 
> ``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/