Re: [Bug-readline] documentation of signal handling

[frederik]

Hi Chet,

It's coming up on the anniversary of my request for documentation of
the Readline 6.3 signal handling changes, so I decided to ping you
again.

I'm looking at this file:

http://git.savannah.gnu.org/cgit/readline.git/tree/examples/rl-callbacktest.c?h=devel

I see you added a SIGWINCH handler in August:

http://git.savannah.gnu.org/cgit/readline.git/commit/examples/rl-callbacktest.c?h=devel&id=f46c78d1e48134bf66588b7d24e64efa7a460b17

However, the example program still exits on SIGINT. Since the vast
majority of Readline clients (gdb, R, Python) do not exit on SIGINT,
many of these experienced problems when Readline changed to stop
handling SIGINT internally. Now these clients have to use an
undocumented sequence of invocations to get the old ^C behavior, such
as the one shown here:

https://bugs.r-project.org/bugzilla/attachment.cgi?id=2070

The requirement for such client-side changes should have been widely
publicized with the release of 6.3 in 2014, but it was not. Now we are
on 7.0 and the callback interface example still does not contain an
example of the new incantations necessary to get correct ^C behavior.

When you have time, would you be so kind as to update
"examples/rl-callbacktest.c" with a working SIGINT handler?

Thank you,

Frederick

On Mon, May 02, 2016 at 01:42:23PM -0700, address@hidden wrote:
> > > You said "Sometimes applications don't want to kill
> > > the current line on SIGINT" but (1) do you know of any examples? 
> > 
> > Sure.  An interactive bash with line editing active that traps SIGINT.
> 
> I see.
> 
> > > Why would such an application want Readline to delete the undo list,
> > > clear the message area, and cancel any keyboard macros, if it is not
> > > going to clear the line? I think application writers expect the line
> > > to be cleared
> > 
> > Deleting the undo list might be iffy, but the others seem reasonable.
> 
> FWIW, Zsh does all (default) or nothing (if you 'trap "" SIGINT').
> 
> Perhaps when you work on the updated examples, that will be a good
> time to think about what the best interface is. I think that the
> client application should be able to tell Readline not to handle
> SIGINT at all; and I think this should be what happens when you trap
> SIGINT in interactive Bash.
> 
> > > (Please let me know if I'm mistaken about this. Does glibc block
> > > SIGINT around functions like malloc()?)
> > 
> > No.  glibc blocks SIGINT very rarely, but uses locks pervasively.
> 
> I see, thank you.
> 
> > > So apparently in addition to the isearch-SIGINT bug which affects the
> > > callback interface (creating a dangerous situation which causes
> > > undesired lines to be entered at the prompt!) there is also a problem
> > > in that users of the basic readline() interface don't even know how to
> > > safely achieve the familiar behavior of clearing a line on ^C.
> > 
> > Take a breath.  In this case, siglongjmp is probably ok, since you know
> > you're not interrupting any unsafe calls in the readline library code.
> > All the code I posted is safe to execute from a signal handler.
> 
> I noticed that after sending my email. However, I later noticed that
> readline() calls
> 
>   rl_set_prompt (prompt);
> 
> before
> 
>   rl_set_signals ();
> 
> which seems to provide a small window for memory corruption /
> deadlock, so perhaps these should be re-ordered?
> 
> Thank you,
> 
> Frederick
> 
> _______________________________________________
> Bug-readline mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/bug-readline
>