summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--libguile/__scm.h26
1 files changed, 26 insertions, 0 deletions
diff --git a/libguile/__scm.h b/libguile/__scm.h
index 5581c8a4b..6ab774cd6 100644
--- a/libguile/__scm.h
+++ b/libguile/__scm.h
@@ -482,6 +482,32 @@ do { \
#define SCM_FENCE
#endif
+/* In the old days, SCM_DEFER_INTS stopped signal handlers from running,
+ since in those days the handler directly ran scheme code, and that had to
+ be avoided when the heap was not in a consistent state etc. And since
+ the scheme code could do a stack swapping new continuation etc, signals
+ had to be deferred around various C library functions which were not safe
+ or not known to be safe to swap away, which was a lot of stuff.
+
+ These days signals are implemented with asyncs and don't directly run
+ scheme code in the handler, but hold it until an SCM_TICK etc where it
+ will be safe. This means interrupt protection is not needed and
+ SCM_DEFER_INTS / SCM_ALLOW_INTS is something of an anachronism.
+
+ What past SCM_DEFER_INTS usage also did though was indicate code that was
+ not reentrant, ie. could not be reentered by signal handler code. The
+ present definitions are a mutex lock, affording that reentrancy
+ protection against the new guile 1.8 free-running posix threads.
+
+ One big problem with the present defintions though is that code which
+ throws an error from within a DEFER/ALLOW region will leave the
+ defer_mutex locked and hence hang other threads that attempt to enter a
+ similar DEFER/ALLOW region.
+
+ The plan is to migrate reentrancy protection to an explicit mutex
+ (private or global, with unwind where necessary), and remove the
+ remaining DEFER/ALLOWs. */
+
#define SCM_DEFER_INTS scm_rec_mutex_lock (&scm_i_defer_mutex);
#define SCM_ALLOW_INTS scm_rec_mutex_unlock (&scm_i_defer_mutex);