Mike Kupfer writes:
Stephen J. Turnbull wrote:
> Reviewers: If you have a clue about Unix processes, please check my
> analysis below, especially with respect to the call of
> deactivate_process() in execute_internal_event() (event-stream.c).
I can't speak to the exact scenario that you listed, but it does seem
plausible that XEmacs would try to write to a subprocess, the subprocess
exits for whatever reason, and XEmacs doesn't handle the cleanup
properly.
I have a backtrace for the exact scenario. I meant to put it on the
tracker for posterity (and because there's a related layering issue
earlier pointed out by Jan Vroonhof), but haven't done so yet.
> I would like to do the signal(2) dance in the relevant Lstream
> implementation (filedesc), but it doesn't know about pipes and
> processes, only about FDs. Is it worth creating a pipe-specific
> variant of the filedesc Lstream?
I wonder what select(2) does if the other end of the pipe has gone
away. That might be a way for the Lstream code to tell whether it
should try to write to the fd.
On Mac OS X it returns EBADF. Thanks for the suggestion, I will
investigate. As you say this is probably not worth it here because it
doesn't fix the race condition, but it might be useful.
On the other hand, even if that worked, there'd still a very
small
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
signal.
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.
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
confirmation.
_______________________________________________
XEmacs-Patches mailing list
XEmacs-Patches(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-patches