Re: [AC 21.5] Prevent SIGPIPE in deactivate_process
Mike Kupfer writes:
I don't see a huge difference here, either, but then I don't
like either
choice. I think we can do better with EPIPE. It's true that unprepared
code won't do all the cleanup that we want, but I expect there would be
some sort of error passed back to the user.
Yeah, probably, but I don't see how that's any better that what we
currently have. And you still need a *global* ignore on the SIGPIPE.
I'm guessing the worst we would see are resource leaks (memory
and
zombie child processes). I'd rather have some resource leaks than
a crash.
Well, crashes are typically easier to diagnose than resource leaks.
And if you want we can have a global SIGPIPE handler that ignores.
Or are there nasty side effects from failing to do proper cleanup
that I'm failing to consider?
Infloops. If we don't catch the EPIPE, then our end of the pipe is
still open AFA XEmacs CT. "Heh heh heh Beavis, that was fun!" "Yeah
Butthead, let's do that again!"
I don't see why I'd have to do an exhaustive code flow
analysis. I
think that once the Lstream code starts seeing EPIPE,
Sure, assuming it does. But we're talking about situations where the
competent and responsible code doesn't see the EPIPE somehow.
Or at least that's the theory. I grant that there are a lot of
suppositions here. I'm well aware that once I actually start coding and
testing, I could run into issues that would make me reconsider this
whole idea.
Unlikely. I agree with your theory, but it hinges on the assumption
that we sort of know what can go wrong. The problem with that
assumption is that as far as we know, nothing can go wrong. So if
something does go wrong, by definition, we know very little about
it.:-)
I'll think about that, but I'm not convinced. process-unix.c
and nas.c
each has its own handler.
Yeah, I know that NAS has a separate handler. I need to look at that
at some point, but AFAIK NAS is basically a dead letter these days.
Even I don't build it in anymore, although around 2000 I thought it
was one of the coolest features of XEmacs.
_______________________________________________
XEmacs-Patches mailing list
XEmacs-Patches(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-patches