SBCL makes extensive use of POSIX signals for such tasks as garbage collection, error handling, and ensuring that atomic operations are executed atomically. MacOS X supports POSIX-style signals, but there are some problems with Apple's BSD-style, as they call it, signalling mechanism. The main problem, viz SBCL, is that MacOS X's signal
implementation and GDB interact in such a way that renders GDB basically useless for debugging SBCL. SBCL's strategy of protecting memory pages with mprotect and then using a signal (usually SIGBUS or SIGSEGV, and SIGBUS in the case of MacOS X) handler to either adjust the memory protection mode and take apporpriate action or to signal an error causes MacOS to issue a mach exception (EXC_BAD_ACCESS) which is then caught be the kernel and causes a SIGBUS to be sent to the offending process. Unfortunately, GDB can't be used to continue past the offending mach exception, so the process just continues to send the exception and never issues the signal to the listening process or moves the program counter past the offending instruction.
In addition to the SIGBUS debugging problems, the signalling mechanism of MacOS X on Intel poses other problems in that MacOS' delivery of SIGTRAP signals is unreliable. It generally works, but only about 95%
of the time. This is unacceptable for SBCL's use as a mechanism for signalling when operations that are supposed to be atomic have been interrupted and that approriate action needs to be taken. We have worked around the SIGTRAP problems by using the UDA2 instruction to cause a SIGILL signal to be delivered to the SBCL process. This works
reliably, but causes the MacOS X on Intel code to differ from other Intel-based platforms.
Finally, Apple's crash reporter doesn't realize that we might be using memory protections and the associated SIGBUS messages for non-crashing, expected behavior and generates a crash log message or, depending on the Crash Reporter preferences, a dialog message to appear on the screen.
These issues are enough to motivate me to consider using Mach exceptions instead of or, more likely, in addition to POSIX/BSD-style signals.
If only it were that simple. Gory details to follow...