[Ecls-list] More thoughts on signals, stack overflows, etc

[Juan Jose Garcia-Ripoll]

On Mon, Oct 6, 2008 at 11:23 PM, Juan Jose Garcia-Ripoll
<juanjose.garciaripoll at googlemail.com> wrote:
> - We forbid calling longjmp from the signal handler. Then ECL has to
>  a) Defer harmless signals wating for a safe place to call them.
>  b) Abort on complicated signals.

I have found what might be an efficient way to implement this
mechanism using a technique which is also used in some JVM
impementations.

The idea would be to allocate a separate memory page for the lisp
environment using mmap. When a signal comes in, we store the relevant
information about the signal into the environment and this page is
protected from writing using mprotect(). Then the signal handler
immediately returns. Whenever the program writes to the lisp
environment (and this happens quite often), if there was a pending
interrupt, our handler will be reentered and we will be able to
execute whatever code we want, because this time the signal comes from
a "safe" place.

This is still intrusive when it comes to embedding ECL, but the whole
mechanism might be deactivated using a run time flag. As for race
conditions and other problems, if we deactivate signals from inside
the signal handler itself using sigaction's flags, then I think we are
pretty safe, but the whole mechanism would break in two circumstances

- When some feature is missing, such as signal() or sigaction(), or
most important, mprotect().
- When we face a non recoverable signal, such as SIGSEGV due to a
stack overflow.

In the first case we would still have to resort to the old way of
checking a pending signal bit and calling the appropriate signal
handler. In the second case, we might resort to the second mechanism,
which is to establish an outermost handler for stack overflows which
we can jump to.

Juanjo

-- 
Instituto de Física Fundamental, CSICJuan
c/ Serrano, 113b, Madrid 28009 (Spain)
http://juanjose.garciaripoll.googlepages.com