0.8.12.36:

	Commit patch from Juho Snellman (sbcl-devel 2004-07-16) for poor
	performance characteristics in sig_stop_for_gc_handler.
	... maybe a spinlock isn't right?  Maybe we should have a
		yielding_spinlock?  Maybe we should have a different
		spinlock implementation for SMP?
	... in any case, performance now should be better for GCing when
		more than two threads are around.

diff --git a/src/runtime/interrupt.c b/src/runtime/interrupt.c
index 519b46f..e277dde 100644 (file)
--- a/src/runtime/interrupt.c
+++ b/src/runtime/interrupt.c
@@ -552,6 +552,16 @@ sig_stop_for_gc_handler(int signal, siginfo_t *info, void *void_context)
     sigset_t ss;
     int i;
     
+    /* KLUDGE: at least on Linux, the kernel apparently schedules a
+       thread immediately it is signalled.  However, we signal
+       SIG_STOP_FOR_GC while holding the spinlock, and consequently we
+       can easily end up with a kind of thundering herd of threads all
+       wanting to acquire the lock at the same time so that they can
+       tell the system that they've gone to sleep.  So we yield here.
+       Whether this is the right fix or not is unknown.  -- CSR,
+       2004-07-16 */
+    sched_yield();
+
     if(maybe_defer_handler(sig_stop_for_gc_handler,data,
                           signal,info,context)) {
        return;

diff --git a/version.lisp-expr b/version.lisp-expr
index 3396edb..b43de9a 100644 (file)
--- a/version.lisp-expr
+++ b/version.lisp-expr
@@ -17,4 +17,4 @@
 ;;; checkins which aren't released. (And occasionally for internal
 ;;; versions, especially for internal versions off the main CVS
 ;;; branch, it gets hairier, e.g. "0.pre7.14.flaky4.13".)
-"0.8.12.35"
+"0.8.12.36"