Re: [AC 21.5] Prevent SIGPIPE in deactivate_process
Mike Kupfer writes:
I still think a cleaner solution is possible without a major rewrite
to
the Lstream code, or a separate Lstream implementation for pipes. Just
have the Lstream code ignore SIGPIPE,
That's "clean", but it also requires a syscall, which will slow things
down if we do it at too low level. We could have XEmacs itself ignore
SIGPIPE, but then I suspect that code that improperly ignores EPIPE
will be hard to detect and hard to diagnose when it causes a bug. Ie,
here SIGPIPE functions (to some extent) like an assert.
It might be a good idea to have XEmacs catch SIGPIPE globally, and
just throw to top-level if the code isn't otherwise prepared for it.
Having a subprocess go away should not be fatal to XEmacs (just as
having the last connected display go away should not be fatal if
gnuserv is running).
and have it pass EPIPE failures up to the caller.
Why do you think the caller will necessarily be prepared for an EPIPE?
unix_send_process() would need some changes, but IMO that would
mostly be getting rid of unnecessary complexity.
Patches welcome!
If that's a larger change than you want to tackle at this time, I
can't
argue with that. It's your time, after all. :-)
Doesn't have to be *my* time. :-)
One thing that bothers is that the event loop code can run inside some
of these functions, in particular unix_send_process. That means that
anything can happen. Do you have an intuition that in practice
nothing will happen? :-) I could just be seeing ghosts, but given my
state of 95% ignorance, I can't quite justify disbelieving in them!
_______________________________________________
XEmacs-Patches mailing list
XEmacs-Patches(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-patches