Daniel Barlow <firstname.lastname@example.org> wrote:
| email@example.com (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 Warnock, PP-ASEL-IA <firstname.lastname@example.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607