I don't know how to get the same behavior using the condition system as you suggest.

In a "real" application,  the SIGSEGV usually occurs in code involving nested loops with arithmetic expressions involving elements of arrays that have been constructed in the mmapped regions.   The responsibility of the SIGSEGV handler is to populate the elements
of "pages" of these arrays on demand.  For example,  consider accessing the tiles of a very large TIFF tiled JPEG image, whose tiles are a multiple of PAGE-SIZE (4096 bytes) in size.    POSIX mmap is used to define a region of virtual memory corresponding to the decompressed image.  Initially, each page is set to PROT_NONE.    When a tile is accessed that hasn't yet been decompressed, a memory-fault occurs.  The responsibility of the sigsegv-handler is to decompress the corresponding tile of the TIFF JPEG image into the mmapped page(s), AND THEN RESUME execution of the code causing the segfault, which actually causes the instruction causing the SIGSEGV to be reexecuted. 

This is exactly the same machinery used by the operating system for handing memory "page-faults", and the mechanism used by SBCL (and CMUCL) GENCGC to implement the garbage collector write-barrier.

Gábor Melis wrote:
On Viernes 24 Abril 2009, Lynn Quam wrote:
I figured out how to *RESUME* execution after handling SIGSEGV.  Here
is an example:

Simply changing error to cerror in memory-fault-error and calling 
mprotect from a handler-bind handler would accomplish the same with or 
am I overlooking something?