[Top][All Lists]

[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: Mon, 9 Jan 2023 11:48:56 -0500
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.6.1

On 1/9/23 8:59 AM, Andrew Burgess wrote:

A grep on the GDB source tree indicates we don't set
rl_signal_event_hook anywhere.  I'll take a look now at the role that
plays in this process and see if it will help at all, but I'd also
welcome any insights you have.

The idea of the event hook is an application-specific event handler that
can be called after read is interrupted by a signal. The application is
the `agent' that has to decide what the effect of the signal should be.
To use bash as an example -- which does not use the callback interface --
it's the difference between what you do when SIGINT is trapped and when
it's set to the default disposition. Readline is agnostic in that regard.

So we're back to mismatched expectations. Readline is expecting the
application to abort the operation, and gdb expects readline to enforce
some behavior internally. We have a policy issue.

It's pretty clear that the desired behavior, at least for the purposes of
this report, here in the case of SIGINT during `stateful' operations like
search or digit-argument input is to abort, in the absence of any other
guidance from the application.

The question is who makes that decision, or at least enforces it. Should
readline impose some sort of default rl_abort behavior in the case that
application doesn't? That's easy enough to do in the signal cleanup path.
Or should it leave it completely up to the application to decide when to
call rl_abort or some other return to the top-levep REPL?

``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]