From: Paul Eggert <eggert@cs.ucla.edu>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 8855@debbugs.gnu.org
Subject: bug#8855: dbus error at startup
Date: Thu, 25 Oct 2012 13:57:40 -0700 [thread overview]
Message-ID: <5089A7C4.2090800@cs.ucla.edu> (raw)
In-Reply-To: <83y5iua59n.fsf@gnu.org>
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.
next prev parent reply other threads:[~2012-10-25 20:57 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-13 17:49 bug#8855: dbus error at startup Dan Nicolaescu
2011-06-26 10:22 ` Michael Albinus
2012-10-25 5:35 ` Paul Eggert
2012-10-25 16:24 ` Eli Zaretskii
2012-10-25 20:57 ` Paul Eggert [this message]
2012-10-29 1:38 ` Paul Eggert
2012-10-29 9:24 ` Chong Yidong
2012-10-29 17:06 ` Eli Zaretskii
2012-10-31 7:36 ` Paul Eggert
2012-10-29 6:27 ` bug#8855: confirmation from glib side Paul Eggert
2012-11-03 18:34 ` bug#8855: installed patch into trunk Paul Eggert
2012-11-27 2:32 ` bug#8855: Fix backported to Emacs 24 Paul Eggert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5089A7C4.2090800@cs.ucla.edu \
--to=eggert@cs.ucla.edu \
--cc=8855@debbugs.gnu.org \
--cc=eliz@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.