bug#14474: 24.3.50; Zombie subprocesses (again)

[Colin Walters]

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.