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: Neil Jerram
Subject: Re: Idea for safe signal handling by a byte code interpreter
Date: 23 Mar 2001 08:58:03 +0000
User-agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.5

>>>>> "Karl" == Karl M Hegbloom <address@hidden> writes:

    Karl>  Then, from strategic points within the VM, just as the
    Karl> emacsen check for QUIT, you'd check for that signal flag or
    Karl> counter, and run the signal handlers from a bottom half of
    Karl> some kind.  This way, you know that the interpretter is in a
    Karl> consistent state and that you're not halfway through
    Karl> something that ought be more atomic, or whatever.

    Karl>  There should be a way to say that "this is a critical
    Karl> section; don't call signal handler here" in the scripting
    Karl> language.

As far as I understand (both your point and the Guile code), this is
what Guile does already.  The signal handler for signal SIG sets
got_signal[SIG] to 1, and marks a system async to run at the next safe
point.  (A system async is simply a thunk that can be marked for
asynchronous execution.)  Guile checks whether it is safe to run
system asyncs in the macros SCM_ALLOW_INTS and SCM_REALLOW_INTS; thus,
in the Guile C code, the code between SCM_DEFER_INTS and
SCM_ALLOW_INTS, or between SCM_REDEFER_INTS and SCM_REALLOW_INTS, is a
critical section as you suggest.

Best regards,
        Neil



reply via email to

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