guile-devel
[Top][All Lists]
Advanced

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

Re: Idea for safe signal handling by a byte code interpreter


From: Hong Zhang
Subject: Re: Idea for safe signal handling by a byte code interpreter
Date: Thu, 22 Mar 2001 12:46:25 -0800

Here is some of my experience with HotSpot for Linux port.

>  I've read, in the glibc info manuals, the the similar situation
>  exists in C programming -- you don't want to do a lot inside the
>  signal handler; just set a flag and return, then check that flag from
>  your main loop, and run a "bottom half".

It is much more limited than you read. Even the sprintf() does not
work well. The sprintf() support "%m", which means errno. The errno
is "#define errno *__errno_location()", which uses thread_self().
If you install signal handler with alternative signal stack.
The sprintf() will crash immediately, even you use empty format string.

>  I've looked, a little, (and months ago at that) at the LibREP (ala
>  "sawfish") virtual machine.  It's a pretty good indirect threaded VM
>  that uses techniques pioneered by Forth engines.  It utilizes the GCC
>  ability to take the address of a label to build a jump table indexed
>  by opcode.  Very efficient.

It is not very portable. I don't believe it will be any faster than
switch case.

>  What if, at the C level, you had a signal handler that sets or
>  increments a flag or counter, stuffs a struct with information about
>  the signal's context, then pushes (by "push", I mean "(cons v ls)",
>  not "(append! ls v)" 'whatever ;-) that struct on a stack...

I don't believe there is any way to push anything on the stack inside
signal handler without breaking the interpreter. Remember the signal
context is not useful outside signal handler.

For synchronous signal, we can use regular signal handler or win32
structured exception handler, for things like SIGSEGV etc.

For asynchronous singal handler, we have to do some magic things.
If you don't need signal context (most of time), you can use a generic
signal handler,

void perl_signal_handler(int sig) {
    /* this is thread safe, SMP safe, nested signal safe */
    atomic_increment(&signal_table[sig]);
    /* set general flag for all async event */
    async_flag = 1;
}

If you really need signal context, you have to use a dedicated thread

void* thread_function(void* arg) {
    while (sigwaitinfo(&sigset, &siginfo)) {
        /* handle signal here */
    }
    /* something wrong */
}

Hong




reply via email to

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