Monthly Archives: February 2017

SBCL: with-timeout Is a Nice Undocumented Feature

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)
           (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.

    (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.


SBCL: Testsuites Cannot Prevent All Possible Bugs

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)
        (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
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.