- ;; multiprocessing support
- ;;
- ;; This is not maintained or tested in current SBCL. I haven't gone out
- ;; of my way to break it, but since it's derived from an old version of
- ;; CMU CL where multiprocessing was pretty shaky, it's likely to be very
- ;; flaky now.
- ;; :MP enables multiprocessing
- ;; :MP-I486 is used, only within the multiprocessing code, to control
- ;; what seems to control processor-version-specific code. It's
- ;; probably for 486 or later, i.e. could be set as long as
- ;; you know you're not running on a 386, but it doesn't seem
- ;; to be documented anywhere, so that's just a guess.
- ; :mp
- ; :mp-i486
+ ;; low-level thread primitives support
+ ;;
+ ;; As of SBCL 0.8, this is only supposed to work in x86 Linux, on which
+ ;; system it's implemented using clone(2) and the %fs segment register.
+ ;; Note that no consistent effort to audit the SBCL library code for
+ ;; thread safety has been performed, so caveat executor.
+ ; :sb-thread
+
+ ;; Kernel support for futexes (so-called "fast userspace mutexes") is
+ ;; available in Linux 2.6 and some versions of 2.4 (Red Hat vendor
+ ;; kernels, possibly other vendors too). We can take advantage of
+ ;; these to do faster and probably more reliable mutex and condition
+ ;; variable support. An SBCL built with this feature will fall back
+ ;; to the old system if the futex() syscall is not available at
+ ;; runtime
+ ; :sb-futex
+
+ ;; Support for detection of unportable code (when applied to the
+ ;; COMMON-LISP package, or SBCL-internal pacakges) or bad-neighbourly
+ ;; code (when applied to user-level packages), relating to material
+ ;; alteration to packages or to bindings in symbols in packages.
+ :sb-package-locks