bug-readline
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: callback api, isearch, signals issue


From: Chet Ramey
Subject: Re: callback api, isearch, signals issue
Date: Wed, 11 Jan 2023 09:33:11 -0500
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.6.1

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.

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/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]