GNU bug report logs - #14474
24.3.50; Zombie subprocesses (again)

Previous Next

Full log

View this message in rfc822 format

From: Colin Walters <walters <at> verbum.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Michael Heerdegen <michael_heerdegen <at> web.de>, 14474 <at> debbugs.gnu.org
Subject: bug#14474: 24.3.50; Zombie subprocesses (again)
Date: Mon, 27 May 2013 08:46:20 -0400

On Sun, 2013-05-26 at 18:36 -0700, Paul Eggert wrote:

> but that's already the case in the Emacs trunk.
> Is there another limitation that we
> didn't know about, a limitation that says Emacs can't
> have signal handlers either?

Basically it's going to be very hard over time to avoid codepaths
in the GTK+ stack that don't call g_spawn_*() indirectly, thus
installing a SIGCHLD handler, particuarly due to the pluggable nature of
Gio.

> I'll CC: this to Colin Walters since he seemed to have
> a good handle on the situation from the glib point of view; see
> <https://bugzilla.gnome.org/show_bug.cgi?id=676167>.

Yeah, I don't think much has changed since then.

> One possibility is to see if we can get Emacs to use
> glib's child watcher.

That'd be best obviously.

>   But that's a bit of a delicate balance,
> since Emacs must work even when gtk is absent,

Bear in mind that GLib is usable without gtk.  Even if you don't
have an X connection, if the GLib mainloop is linked into the process,
I don't see a reason not to use it.

>  and it may need
> to hand off from its own watcher to glib's watcher, and processes
> shouldn't get lost during the handoff. 

Would Emacs really be spawning processes before initializing
the frontend?

> A simpler but hacky workaround is to not use the graphical interface if
> DBUS_SESSION_BUS_ADDRESS is unset.

I don't see a real problem with that as a temporary thing.

Anyways, if there is something I can do GLib side, let me know.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.