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 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 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.
I will revert this patch on request. I don't really have an idea
of
what bad things could happen if we fail to flush to a live process
that is about to be terminated, but if somebody thinks that's a risk,
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.
mike
_______________________________________________
XEmacs-Patches mailing list
XEmacs-Patches(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-patches