Re: [AC 21.5] Prevent SIGPIPE in deactivate_process
Stephen J. Turnbull wrote:
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.
Well, it would add two system calls per write system call (one to ignore
SIGPIPE, the other to restore the default handler). I don't have a
sense for how much this would slow things down in practice, but I
acknowledge it's a potentially fatal problem with my proposal. Maybe
there's a clean way to configure the Lstream when it's set up, so that
only pipes get this treatment (without having a whole new Lstream
implementation just for pipes).
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).
The thing that makes me nervous about this approach is that it could
leave internal state messed up. Any calls that could cause an Lstream
write would have to be done in a place where it's okay if processing is
thrown back to top-level.
> 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 to be changed, of course. The reason I'm
not worried about arbitrary callers is that I'm assuming they're coded
to check for a few specific errors, and to bail out for any other
errors. I think EPIPE will fit into that framework. OTOH, my
understanding of XEmacs internals is pretty meager, so I concede this
could be a case of "ignorance is bliss".
> unix_send_process() would need some changes, but IMO that
would
> mostly be getting rid of unnecessary complexity.
Patches welcome!
Okay, I'll add this to my list of things to hack on. In the meantime, I
don't want to hold up your fix. And to clarify a remark I made
yesterday, I think that your refactoring of the Lstream close code is
perfectly reasonable for the long term, as there may be other situations
where we want a close-no-flush function.
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!
This is sort of why I had second thoughts about having
unix_send_process() just set the SIGPIPE handler once. I didn't
realize that the event handler could run. I was worried about what
might break if XEmacs did a longjmp while cleaning up from an exiting
child.
If anything, my intuition is that all sorts of chaos is possible.
That's why I want to ignore SIGPIPE (remove asynchronous flows of
execution from the mix).
mike
_______________________________________________
XEmacs-Patches mailing list
XEmacs-Patches(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-patches