You appear to be correct.  I am able to successfully run code similar to this example.
Looking at the SBCL sources I got the wrong impression that SIGSEGV would not be handled
using the condition system.  Wrong conclusion.

Gábor Melis wrote:
On Lunes 20 Abril 2009, Lynn Quam wrote:
  
It appears that in CMUCL it possible to handle SIGSEGV conditions.

    
(defun mmap-anonymous-region (size prot)
  (unix::unix-mmap nil size prot (logior UNIX:MAP_ANONYMOUS
unix::MAP_PRIVATE) nil 0))

(defparameter *mmap-sap* (mmap-anonymous-region (* 4
(SYS:GET-PAGE-SIZE )) unix::PROT_NONE))

(handler-case (progn (unix:unix-mprotect *mmap-sap* (* 4
(sys:get-page-size )) unix::prot_read)
             (setf (sys::sap-ref-32 *mmap-sap* 0) 1))
  (error ()
    (unix:unix-mprotect *mmap-sap* (* 4 (sys:get-page-size ))
unix::prot_write)
    (setf (sys::sap-ref-32 *mmap-sap* 0) 1)
    ))
      
Has SBCL diverged from CMUCL in this regard?
    

This does not _resume_ the code that caused the fault. I probably took 
your original question too literally and even then the answer was quite 
wrong. Similar code should work on sbcl too, at least after adding 
mprotect to sb-posix, but that does not allow you to actually resume 
the code.

Signalling memory-fault-error with cerror in interr.lisp would allow you 
to unprotect the page, do whatever is needed, and continue. However, 
the reported fault address is not reliable on multithreaded builds as 
it's passed via a global variable.