bug#8855: dbus error at startup

[Paul Eggert <eggert@cs.ucla.edu>]

On 10/25/2012 09:24 AM, Eli Zaretskii wrote:
> is there perhaps a way to fix this less intrusively,
> without messing with the whole chain of functions involved in SIGCHLD
> and subprocess termination?

I looked for one but couldn't find one.

We could try to get the glib API fixed, but I can't offhand
think of an easy fix, and in the meantime we need to deal
with the glibs in the field with the current API, and for
those glibs we need a workaround anyway.

We could try to use process groups, so that Emacs invokes
waitpid just on a process group rather than on all children.
However, an executable can create a new process group and
join it so this would require that we create two processes
instead of one (the child simply forks and waits for the
grandchild which does the real work, so that any mucking
around by the grandchild cannot affect the child's process
group).  This would work, but it costs us one extra process
per subprocess, and I expect that in practice that'd be
worse than the proposed patch, both performance-wise and
intrusive-change-wise.

glib itself, when faced with this problem, does not use
process groups, but simply scans for all subprocesses that
it knows about, just as the proposed patch does.  See the
function dispatch_unix_signals in glib/gmain.c.

Looking at that function's callers, it may be that we can
use g_child_watch_source_new instead of waitpid, but it's
not clear to me how that would work, and I wonder whether the
result would be any less intrusive than the proposed patch.