Peter Seibel <firstname.lastname@example.org> wrote:
| Given the flexibility of the condition system for managing
| coordination of code at different levels of the call stack, I'm having
| a hard time thinking of what I'd use CATCH/THROW for.
| Does anyone have any favorite idioms they still use that feature
I ran into a situation just last week where CATCH/THROW was what came
first to mind as a solution, though thinking back on it I suppose I
could have used conditions just as easily...
Under Unix a given process can be in only one state at a time w.r.t. the
handling of a given Unix signal, but in implementations such as CMUCL
(on x86) which provide "green threads", you often want different
threads to handle signals differently, at least in their control-flow
responses. In particular, I wanted a SIGPIPE (which is what you get if
your web server code is writing to a socket and a user hits the <STOP>
button on the client browser) to be handled by the thread that was writing
to the closed socket, *not* the MP::*INITIAL-PROCESS*. My perhaps-ugly
solution was as follows:
In the global initialization code:
(defun sigpipe-handler (signal code scp)
(declare (ignore signal code scp))
(throw 'sigpipe 'sigpipe))
;; Remember initial state & enable local handler.
(system:enable-interrupt :sigpipe #'sigpipe-handler))
In the per-thread server code [where the worker routine SERVE-REQUEST-1
will in the normal case do a (progn (finish-output stream) (close stream))
(defun serve-request (func request)
(let ((stream (http-request-stream request)))
(when (eq 'sigpipe (catch 'sigpipe
(serve-request-1 func request stream)))
(log-msg "serve-request[~d]: SIGPIPE on fd ~d: ~a"
(http-request-self request)) ; sanitized URI
;; Avoid fd leakage.
(ignore-errors (close stream :abort t))))) ; 
Note: SIGPIPE always occurs during a "write()" system call [or "close()",
which is why the above code keeps the CATCH active around the (close stream)
in SERVE-REQUEST-1] and thus is thread-synchronous, and thus the THROW
in the handler will be in the same thread context as the CATCH wrapped
around the offending "write()". [Caution: The same will *not* necessarily
be true for other Unix signals.]
If someone has something significantly cleaner to suggest, feel free
to do so. As noted at the beginning, I suppose I could have defined a
specific condition and used HANDLER-CASE/ERROR to get the same effect.
But in such a confined context CATCH/THROW seemed more "lightweight"
somehow. [Hmmm... Maybe my former C hacking with setjmp/longjmp bleeding
 That is, within-Unix-process multiprogramming -- what CMUCL *should*
have called it, not "multiprocessing". (Which it isn't -- at least,
not yet. Though SBCL...?)
 By experimentation(!) I discovered that in CMUCL a
(close stream :abort t) will not do any additional "write()"s, and
thus will not cause additional SIGPIPEs to occur. [A previous version
of the handler that just did (ignore-errors (close stream)) had caused
infinite recursion of SIGPIPEs, since each handler entry would try to
CLOSE and eash CLOSE would try to flush the stream, which would cause
a "write()" and... Oops.]
Rob Warnock, PP-ASEL-IA <email@example.com>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607