[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Idea for safe signal handling by a byte code interpreter
From: |
Karl M. Hegbloom |
Subject: |
Idea for safe signal handling by a byte code interpreter |
Date: |
22 Mar 2001 11:15:23 -0800 |
User-agent: |
Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.2 (Thelxepeia (GTK Inside)) |
I've not researched this at all... perhaps it's a "known" way of
doing things and there is research writing out there already, etc...
I've not even looked at this point. I have about 30 minutes to
outline this and bounce it off of you all this morning. 8-)
I was reading Lincoln D. Stein's "Network Programming with Perl" (the
one with that very interesting and nicely done Yggdrasil on the
cover), and got into the part about signal handling. He says that
it's not safe to do a lot of stuff inside a signal handler; that it
can even cause Perl to crash.
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".
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.
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...
When, in your language, you do the equivalent of Perl:
$SIG{'<signame'} = $coderef;
... it would install the C level signal handler for that signal.
Then, from strategic points within the VM, just as the emacsen check
for QUIT, you'd check for that signal flag or counter, and run the
signal handlers from a bottom half of some kind. This way, you know
that the interpretter is in a consistent state and that you're not
halfway through something that ought be more atomic, or whatever.
There should be a way to say that "this is a critical section; don't
call signal handler here" in the scripting language.
--
Perl needs this:
(cond
((cond-exp-one) => (lambda (v) (do-something-with v)))
(else 'whatever))
--
mailto: (Karl M. Hegbloom) address@hidden
http://www.microsharp.com
phone://USA/WA/360-260-2066
- Idea for safe signal handling by a byte code interpreter,
Karl M. Hegbloom <=