[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#14474: 24.3.50; Zombie subprocesses (again)
From: |
Colin Walters |
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.
- bug#14474: 24.3.50; Zombie subprocesses (again), Michael Heerdegen, 2013/05/25
- bug#14474: 24.3.50; Zombie subprocesses (again), Michael Heerdegen, 2013/05/25
- bug#14474: 24.3.50; Zombie subprocesses (again), Eli Zaretskii, 2013/05/25
- bug#14474: 24.3.50; Zombie subprocesses (again), Paul Eggert, 2013/05/26
- bug#14474: 24.3.50; Zombie subprocesses (again), Paul Eggert, 2013/05/31
- bug#14474: 24.3.50; Zombie subprocesses (again), Colin Walters, 2013/05/31