Re: [Bug-readline] documentation of signal handling

[frederik]

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