unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: "Jan Djärv" <jan.h.d@swipnet.se>
To: Paul Eggert <eggert@cs.ucla.edu>
Cc: Michael Heerdegen <michael_heerdegen@web.de>,
	Colin Walters <walters@verbum.org>,
	14474@debbugs.gnu.org
Subject: bug#14474: 24.3.50; Zombie subprocesses (again)
Date: Tue, 28 May 2013 19:04:59 +0200	[thread overview]
Message-ID: <439C96AC-545D-424F-87BD-37815592C7AB@swipnet.se> (raw)
In-Reply-To: <51A399B0.7070203@cs.ucla.edu>

Hello.

27 maj 2013 kl. 19:36 skrev Paul Eggert <eggert@cs.ucla.edu>:

> [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
> 

Actually GLib is linked in whenever one of GSettings, GConf, Gtk or rsvg is used.
I see rsvg only is not handeled in xgselect.c, an oversight.


> * 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?
> 

Keep track of the return value from g_child_watch_add and pass it to g_source_remove.
I think g_source_remove can be called in the callback function.

We kind of use GLibs main loop in xgselect.c, so child watches should be called from there.
As GLib:s main loop is an "all or nothing" approach, we could also move the filedescriptor and timeout handling  there.  Then xgselect.c could more or less go away.  But there is no real gain to do that, xgselect works well enough.

	Jan D.






  parent reply	other threads:[~2013-05-28 17:04 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
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 [this message]
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

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=439C96AC-545D-424F-87BD-37815592C7AB@swipnet.se \
    --to=jan.h.d@swipnet.se \
    --cc=14474@debbugs.gnu.org \
    --cc=eggert@cs.ucla.edu \
    --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 public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).