-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
-}
-