Steel Bank Common Lisp

Update of /cvsroot/sbcl/sbcl/src/code
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv7059/src/code

Modified Files:
	signal.lisp 
Log Message:
0.9.1.7: "fix" SB-SPROF on non-gencgc platforms
   * block some "potentially dangerous, but not really important"
      signals for GC on non-gencgc platforms. see kludge_sigset_for_gc
      for commentary.


Index: signal.lisp
===================================================================
RCS file: /cvsroot/sbcl/sbcl/src/code/signal.lisp,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -d -r1.13 -r1.14
--- signal.lisp	1 Sep 2003 07:55:42 -0000	1.13
+++ signal.lisp	29 May 2005 21:08:46 -0000	1.14
@@ -47,13 +47,20 @@
     `(flet ((,name () ,@body))
        (if *interrupts-enabled*
 	   (unwind-protect
-	       (let ((*interrupts-enabled* nil))
-		 (,name))
+		(let ((*interrupts-enabled* nil))
+		  (,name))
 	     ;; FIXME: Does it matter that an interrupt coming in here
 	     ;; could be executed before any of the pending interrupts?
 	     ;; Or do incoming interrupts have the good grace to check
 	     ;; whether interrupts are pending before executing themselves
 	     ;; immediately?
+	     ;;
+	     ;; FIXME: from the kernel's POV we've already handled the
+	     ;; signal the moment we return from the handler having
+	     ;; decided to defer it, meaning that the kernel is free
+	     ;; to deliver _more_ signals to us... of which we save,
+	     ;; and subsequently handle here, only the last one.
+	     ;; PSEUDO-ATOMIC has the same issue. -- NS 2005-05-19
 	     (when *interrupt-pending*
 	       (receive-pending-interrupt)))
 	   (,name)))))