all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Paul Eggert <eggert@cs.ucla.edu>
To: Colin Walters <walters@verbum.org>
Cc: Michael Heerdegen <michael_heerdegen@web.de>, 14474@debbugs.gnu.org
Subject: bug#14474: 24.3.50; Zombie subprocesses (again)
Date: Mon, 27 May 2013 10:36:48 -0700	[thread overview]
Message-ID: <51A399B0.7070203@cs.ucla.edu> (raw)
In-Reply-To: <1369658780.23869.57.camel@localhost>

[The context is
http://bugs.gnu.org/14474
]

On 05/27/2013 05:46 AM, Colin Walters wrote:

> 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

Thanks.  In that case, shouldn't the glib documentation be
changed to warn application developers not to install a SIGCHLD
handler as well?  Currently it warns them only to not call
waitpid(-1, ...).

Are application developers allowed to temporarily mask SIGCHLD?
Emacs does that a lot.

>> One possibility is to see if we can get Emacs to use
>> > glib's child watcher.
> That'd be best obviously.

I suspect so too, but it requires more expertise in
glib than I have (which is, basically, nothing).
If I understand things correctly, if Emacs is using
Gtk it should

 * never call sigaction (SIGCHLD, ...) or signal (SIGCHLD, ...)
   or waitpid (-1, ...).
   E.g., remove the current call to sigaction (SIGCHLD, ...),
   in src/process.c's init_process_emacs.
   
 * Whenever Emacs creates a child process, use the
   following pattern:

       block SIGCHLD;
       pid = vfork ();
       if (pid > 0)
         {
           record pid in Emacs's process table, as location 'loc';
           record in *loc that glib is watching this pid;
           g_child_watch_add (pid, watcher, loc);
         }
       unblock SIGCHLD;

  * never call waitpid (pid, ...) if PID is recorded
    in Emacs's process table as something that glib is
    watching.

  * Add a glue function ("watcher", above) that does
    something like this:

      void watcher (GPid pid, gint status, gpointer loc) {
	block SIGCHLD
        record that PID exited with status STATUS, by modifying *LOC,
	  sort of like's what currently done in handle_child_signal;
        if (input_available_clear_time)
	  *input_available_clear_time = make_emacs_time (0, 0);
        unblock SIGCHLD
     }

But this sounds incomplete.  No doubt there's something
about the main loop, or setting up the watchers, that I don't
know about.  E.g., how does one remove the watcher once it
has fired and told us that the process has exited?

I'll CC: this to Jan Djärv, who knows about gtk, to
see if he can help.







  reply	other threads:[~2013-05-27 17:36 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-25 23:38 bug#14474: 24.3.50; Zombie subprocesses (again) Michael Heerdegen
2013-05-25 23:49 ` Michael Heerdegen
2013-05-26  2:55 ` Eli Zaretskii
2013-05-26 17:37 ` Paul Eggert
2013-05-26 18:33   ` Michael Heerdegen
2013-05-27  1:36     ` Paul Eggert
2013-05-27 12:46       ` Colin Walters
2013-05-27 17:36         ` Paul Eggert [this message]
2013-05-28 16:56           ` Paul Eggert
2013-05-28 20:42             ` Michael Heerdegen
2013-06-04 17:12             ` Michael Heerdegen
2020-09-09 13:52               ` Lars Ingebrigtsen
2013-05-28 17:04           ` Jan Djärv
2013-06-01  1:03         ` Paul Eggert
2013-06-01  1:22           ` Colin Walters
2013-06-01  6:14             ` Paul Eggert
2013-06-01 14:33               ` Stefan Monnier
2013-06-03 16:09                 ` Colin Walters
2013-06-04  7:20                   ` Paul Eggert
2013-06-05 17:21                     ` 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=51A399B0.7070203@cs.ucla.edu \
    --to=eggert@cs.ucla.edu \
    --cc=14474@debbugs.gnu.org \
    --cc=michael_heerdegen@web.de \
    --cc=walters@verbum.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.