Re: [AC 21.5] Prevent SIGPIPE in deactivate_process
Mike Kupfer writes:
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.
That's already true, since the current consequence is a crash due to
the default fatal handler on SIGPIPE. I don't really see a difference
here, it's a matter of philosophy whether it's nicer to the user to
crash or to leave them in an unknown state when we've screwed up
badly. Either way, we have to admit we've screwed up. ;-)
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.
But we want a specific definition of "bail out" for EPIPE. Ie,
"assume the subprocess died untimely, so politely shutdown our end of
the pipes, finalize the process structures, and then report the error
to the user."
We know that that is the current definition of how to handle SIGPIPE.
I don't see any reason to suppose that is the definition of how to
handle an unknown error throughout all code that might now see an
EPIPE. Checking that seems like a pretty hairy task to me.
> Patches welcome!
Okay, I'll add this to my list of things to hack on.
Well, that's up to you. FWIW, I was sort of joking; I'd be happy to
have an alternative patch to review, but my feeling is that a redesign
is a hairball that we should avoid right now, unless you think you
personally will get something out of this (eg, a better understanding
of parts of XEmacs you want to hack on in the future). I don't see a
guarantee that you'll get an accept-able patch out of it.
N.B. There are other problems in the Lstream code IMO. Specifically,
it's too hard to localize errors and exceptional conditions (such as
the presence of markers and extents) in streams when there are stacked
Lstreams (and stacked Lstreams are very common because of the need to
do Mule-coding in essentially all I/O contexts). If and when we do
something about that, we could revisit the SIGPIPE vs. EPIPE design
decision. If you like that option, we can put a comment in the code
to that effect.
In the meantime, I don't want to hold up your fix.
Oh, that's already committed since it is certainly a fix (I'm just
worried about whether it's introducing other risks, and none have been
pointed out so far).
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).
Sure, that makes sense ... but the current problem is that there are
unremovable (at least within the scope of this discussion)
asynchronous flows of execution that were not protected from SIGPIPE
at all. So ignoring SIGPIPE at a low level doesn't really help this
problem. We still need to check all the possible flows of execution.
One thing that the SIGPIPE approach does is to satisfy DRY. All of
the broken PIPE conditions are handled in the same place, even though
we're calling back into the event loop. Offhand, I don't see how to
do that in the EPIPE approach.
_______________________________________________
XEmacs-Patches mailing list
XEmacs-Patches(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-patches