[Top][All Lists]

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

Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.

From: Paul Eggert
Subject: Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.
Date: Sun, 3 Jan 2016 10:07:21 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0

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.

reply via email to

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