guile-devel
[Top][All Lists]
Advanced

[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



reply via email to

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