Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.

[Paul Eggert <eggert@cs.ucla.edu>]

Daniel Colascione wrote:

 > we don't respond to *unix* signals by longjmping.

Not true. A code path is deliver_interrupt_signal → deliver_process_signal → 
handle_interrupt_signal → handle_interrupt → quit_throw_to_read_char → 
sys_longjmp. For what it's worth, Emacs can also lisp-signal from Unix signal 
handlers if immediate_quit is true. This code has been in Emacs for many years.

> The libsigsegv approach is a problem too: pthread cancellation in
> practice is unsupported on some platforms, does not execute C++
> destructors on some platforms even where it's supported, is lightly
> tested, and conflicts with other uses of sigsegv. In the case of Emacs,
> pthread cancellation is additionally risky because we don't even try to
> PTHREAD_CANCEL_DISABLE around critical code sequences.

Yes, of course we'd have to do some work to take the libsigsegv approach. We 
would need to use pthread cancellation only on platforms where it works, and we 
would need to defer cancellation during critical sections. On platforms that 
lack pthread cancellation or where it doesn't work, we'd be no worse off than we 
are now. If we do the longjmp ourselves I assume we can work around the C++ 
destructor problem the same way we do now.

 From what Eli writes, some of this work (I don't know how much) has already 
been done for the MS-Windows port. It would be helpful to do something similar 
for GNU/Linux and similar platforms, and to do it right by marking critical 
sections etc. All this would make Emacs more bullet-proof, if someone has the 
time to undertake the job.