+void
+kludge_sigset_for_gc(sigset_t * set)
+{
+#ifndef LISP_FEATURE_GENCGC
+ /* FIXME: It is not sure if GENCGC is really right here: maybe this
+ * really affects eg. only Sparc and PPC. And the following KLUDGE
+ * could really use real fixing as well.
+ *
+ * KLUDGE: block some async signals that seem to have the ability
+ * to hang us in an uninterruptible state during GC -- at least
+ * part of the time. The main beneficiary of this is SB-SPROF, as
+ * SIGPROF was almost certain to be eventually triggered at a bad
+ * moment, rendering it virtually useless. SIGINT and SIGIO from
+ * user or eg. Slime also seemed to occasionally do this.
+ *
+ * The problem this papers over appears to be something going awry
+ * in SB-UNIX:RECEIVE-PENDING-SIGNALS at the end of the
+ * WITHOUT-INTERRUPTS in SUB-GC: adding debugging output shows us
+ * leaving the body of W-I, but never entering sigtrap_handler.
+ *
+ * Empirically, it seems that the problem is only triggered if the
+ * GC was triggered/deferred during a PA section, but this is not
+ * a sufficient condition: some collections triggered in such a
+ * manner seem to be able to receive and defer a signal during the
+ * GC without issues. Likewise empirically, it seems that the
+ * problem arises more often with floating point code then not. Eg
+ * (LOOP (* (RANDOM 1.0) (RANDOM 1.0))) will eventually hang if
+ * run with SB-SPROF on, but (LOOP (FOO (MAKE-LIST 24))) will not.
+ * All this makes some badnesss in the interaction between PA and
+ * W-I seem likely, possibly in the form of one or more bad VOPs.
+ *
+ * For additional entertainment on the affected platforms we
+ * currently use an actual illegal instruction to receive pending
+ * interrupts instead of a trap: whether this has any bearing on
+ * the matter is unknown.
+ *
+ * Apparently CMUCL blocks everything but SIGILL for GC on Sparc,
+ * possibly for this very reason.
+ *
+ * -- NS 2005-05-20
+ */
+ sigdelset(set, SIGPROF);
+ sigdelset(set, SIGIO);
+ sigdelset(set, SIGINT);
+#endif
+}
+