Stephen J. Turnbull wrote:
Mike Kupfer writes:
> On the other hand, even if that worked, there'd still a
> window between the select() call and the write(), where the process
> could go away. So maybe it's better to just ignore SIGPIPE. On Unixy
> systems, the write(2) call will still fail; you just won't get the
Of course, we don't want to ignore SIGPIPE, because we need to clean
up our end of the pipe, and the XEmacs structures associated with it.
But we already have the necessary mechanism in place, the question
here is how to connect it without race conditions.
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). 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.
> If the process is about to be terminated, there's no
guarantee that it
> would read the flushed data before exiting anyway. So I don't see this
> as an issue.
Well, not exactly. By terminate I didn't mean "kill -9", I meant any
of the various ways we might politely tell the subprocess to go away
as well. I *think* that "deactivate_process" is only called *after*
we receive a SIGCHLD or other strong indication that the subprocess
has already gone away, and it is never called as (part of) the way to
say "go away". But I'm not experienced in this area either in general
or in the XEmacs process control implementation, so I'd like
Okay. I'll put this on my list of things to look at, in case nobody
gets to it sooner.
XEmacs-Patches mailing list