[Top][All Lists]
[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