Daniel Barlow  <dan@telent.net> wrote:
+---------------
| rpw3@rpw3.org (Rob Warnock) writes:
| 
| > 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
| 
| I found it easier to ignore SIGPIPE altogether.  You still get EPIPE
| back from your write() or close() call (which is passed up to Lisp as 
| some condition you can handle) so you're not losing any information.
+---------------

*Doh!* You're right, of course. That's a lot simpler.  Thanks!

There *is* one reason in my application to distinguish between an EPIPE
and other errors -- for the others I try to write a helpful message back
to the user's browser (as well as an internal log), but for an EPIPE that
won't work, of course. I just have to be careful not to fall into infinite
regress in that case...

+---------------
| The primary use for SIGPIPE seems to be in utilities which don't
| check write() return values, e.g. to ensure that the cat in ``cat
| bigfile | head'' doesn't spin endlessly.
+---------------

Yup. Exactly. But any decent Lisp will check all O/S calls...  ;-}


-Rob

-----
Rob Warnock, PP-ASEL-IA		<rpw3@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607