SBCL has a nice undocumented feature,
(sb-ext:with-timeout expires &body body). As far as I can tell, this is exactly analogous to the same feature in Bordeaux Threads, but that seems undocumented too.
It does not appear in the SBCL manual as of 1.3.14, but it does have a documentation string.
"Execute the body, asynchronously interrupting it and signalling a TIMEOUT condition after at least EXPIRES seconds have passed. Note that it is never safe to unwind from an asynchronous condition. Consider: (defun call-with-foo (function) (let (foo) (unwind-protect (progn (setf foo (get-foo)) (funcall function foo)) (when foo (release-foo foo))))) If TIMEOUT occurs after GET-FOO has executed, but before the assignment, then RELEASE-FOO will be missed. While individual sites like this can be made proof against asynchronous unwinds, this doesn't solve the fundamental issue, as all the frames potentially unwound through need to be proofed, which includes both system and application code -- and in essence proofing everything will make the system uninterruptible."
Here is a little demonstration on how to use it.
(handler-case (sb-ext:with-timeout 3 (format t "Hello, world.~%") (sleep 5) (format t "Goodbye, world.~%")) (sb-ext:timeout (e) (format t "~a~%" e)))
This will print out
Hello, world. Timeout occurred.
On OS X, SBCL as of 1.3.14 can’t sleep after fork. The following simple program exits with an error.
(require 'sb-posix) (let ((pid (sb-posix:fork))) (if (= 0 pid) (progn (format t "Child: Sleeping for 10 seconds.~%") (sleep 10) (format t "Child: I woke up.~%")) (format t "Parent, exiting.~%")))
When the above script is run on OS X, it fails with the weird error we see below. Note that it works perfectly on Linux.
% sbcl --script sleep.cl Parent, exiting. Child: Sleeping for 10 seconds. fatal error encountered in SBCL pid 16145: (ipc/send) invalid destination port
The point of this, is that there is no reasonable way a testsuite will catch this kind of a bug. Testsuites, no matter how comprehensive, will never prevent bugs 100%. At most, they prevent the same bug from reappearing.
Hopefully the SBCL team will fix this bug soon.