Mike Kupfer writes:
I agree that XEmacs needs to find out about the condition and clean
up.
But my understanding is that the SIGPIPE is only generated when XEmacs
tries to write to the pipe. AFAIK, XEmacs doesn't need the asynchronous
notification that a signal provides; it can just check for an error
return from write() (EPIPE).
Well, in my (imperfect) understanding, in theory that's true, but it
would require a new Lstream implementation for pipes, or maybe changes
to the current filedesc implementation (which doesn't expect EPIPE).
Also, some amount of higher-level code would need to be rewritten and
reviewed for race conditions (it is designed to assume a reliable
stream, and to ignore the details of when data is actually written to
the pipe except when an explicit flush is called for).
But for XEmacs to actually get an error return, it either needs to
tell the OS not to generate SIGPIPE, or it needs to ignore SIGPIPE.
Ignoring SIGPIPE seems to be the more portable of the two
approaches.
Except there's a third approach (the one actually implemented in
XEmacs), which is to provide non-fatal SIGPIPE handling. The problem
is that it's buggy. I think my patch fixes it (at least for Unixoid
platforms). The alternatives require bigger changes and maybe a
rethink of the whole Lstream strategy AFAICS. I don't have an
appetite for that.
_______________________________________________
XEmacs-Patches mailing list
XEmacs-Patches(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-patches