Attachment 49046 Details for Bug 39197 – [PATCH 1/5] document how the various processes in dbus-launch interact

[patch] [PATCH 1/5] document how the various processes in dbus-launch interact

0001-document-how-the-various-processes-in-dbus-launch-in.patch (text/plain), 2.54 KB, created by Simon McVittie on 2011-07-13 09:37:24 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Simon McVittie

Created: 2011-07-13 09:37:24 UTC

Size: 2.54 KB

patch

obsolete

>From 87ad0627d8aa8ff55e05dae468b73e526af5408f Mon Sep 17 00:00:00 2001
>From: Simon McVittie <simon.mcvittie@collabora.co.uk>
>Date: Thu, 16 Jun 2011 11:56:30 +0100
>Subject: [PATCH 1/5] document how the various processes in dbus-launch
> interact
>
>---
> tools/dbus-launch.c |   41 +++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 41 insertions(+), 0 deletions(-)
>
>diff --git a/tools/dbus-launch.c b/tools/dbus-launch.c
>index bbaac2c..7b1bb37 100644
>--- a/tools/dbus-launch.c
>+++ b/tools/dbus-launch.c
>@@ -43,6 +43,47 @@
> extern Display *xdisplay;
> #endif
> 
>+/* PROCESSES
>+ *
>+ * If you are in a shell and run "dbus-launch myapp", here is what happens:
>+ *
>+ * shell [*]
>+ *   \- main()               --exec--> myapp[*]
>+ *      \- "intermediate parent"
>+ *         \- bus-runner     --exec--> dbus-daemon --fork
>+ *         \- babysitter[*]            \- final dbus-daemon[*]
>+ *
>+ * Processes marked [*] survive the initial flurry of activity.
>+ *
>+ * If you run "dbus-launch --sh-syntax" then the diagram is the same, except
>+ * that main() prints variables and exits 0 instead of exec'ing myapp.
>+ *
>+ * PIPES
>+ *
>+ * dbus-daemon --print-pid     -> bus_pid_to_launcher_pipe     -> main
>+ * dbus-daemon --print-address -> bus_address_to_launcher_pipe -> main
>+ * main                        -> bus_pid_to_babysitter_pipe   -> babysitter
>+ *
>+ * The intermediate parent looks pretty useless at first glance. Its purpose
>+ * is to avoid the bus-runner becoming a zombie: when the intermediate parent
>+ * terminates, the bus-runner and babysitter are reparented to init, which
>+ * reaps them if they have finished. We can't rely on main() to reap arbitrary
>+ * children because it might exec myapp, after which it can't be relied on to
>+ * reap its children. We *can* rely on main() to reap the intermediate parent,
>+ * because that happens before it execs myapp.
>+ *
>+ * It's unclear why dbus-daemon needs to fork, but we explicitly tell it to
>+ * for some reason, then wait for it. If we left it undefined, a forking
>+ * dbus-daemon would get the parent process reparented to init and reaped
>+ * when the intermediate parent terminated, and a non-forking dbus-daemon
>+ * would get reparented to init and carry on there.
>+ *
>+ * myapp is exec'd by the process that initially ran main() so that it's
>+ * the shell's child, so the shell knows how to do job control and stuff.
>+ * This is desirable for the "dbus-launch an application" use-case, less so
>+ * for the "dbus-launch a test suite in an isolated session" use-case.
>+ */
>+
> static char* machine_uuid = NULL;
> 
> const char*
>-- 
>1.7.5.4
>

Actions: View | Splinter Review

Attachments on bug 39197: 49046 | 49047 | 49048 | 49049 | 49050 | 56718 | 56719 | 56720 | 56721 | 56722 | 63464 | 80363 | 80364

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.