+ g_signal_emit (context, signals[LAUNCH_FAILED], 0, startup_notify_id);
+}
+
+
+/**
+ * SECTION:gappinfomonitor
+ * @short_description: Monitor application information for changes
+ *
+ * #GAppInfoMonitor is a very simple object used for monitoring the app
+ * info database for changes (ie: newly installed or removed
+ * applications).
+ *
+ * Call g_app_info_monitor_get() to get a #GAppInfoMonitor and connect
+ * to the "changed" signal.
+ *
+ * In the usual case, applications should try to make note of the change
+ * (doing things like invalidating caches) but not act on it. In
+ * particular, applications should avoid making calls to #GAppInfo APIs
+ * in response to the change signal, deferring these until the time that
+ * the data is actually required. The exception to this case is when
+ * application information is actually being displayed on the screen
+ * (eg: during a search or when the list of all applications is shown).
+ * The reason for this is that changes to the list of installed
+ * applications often come in groups (like during system updates) and
+ * rescanning the list on every change is pointless and expensive.
+ *
+ * Since: 2.40
+ **/
+
+/**
+ * GAppInfoMonitor:
+ *
+ * The only thing you can do with this is to get it via
+ * g_app_info_monitor_get() and connect to the "changed" signal.
+ *
+ * Since: 2.40
+ **/
+
+/* We have one of each of these per main context and hand them out
+ * according to the thread default main context at the time of the call
+ * to g_app_info_monitor_get().
+ *
+ * g_object_unref() is only ever called from the same context, so we
+ * effectively have a single-threaded scenario for each GAppInfoMonitor.
+ *
+ * We use a hashtable to cache the per-context monitor (but we do not
+ * hold a ref). During finalize, we remove it. This is possible
+ * because we don't have to worry about the usual races due to the
+ * single-threaded nature of each object.
+ *
+ * We keep a global list of all contexts that have a monitor for them,
+ * which we have to access under a lock. When we dispatch the events to
+ * be handled in each context, we don't pass the monitor, but the
+ * context itself.
+ *
+ * We dispatch from the GLib worker context, so if we passed the
+ * monitor, we would need to take a ref on it (in case it was destroyed
+ * in its own thread meanwhile). The monitor holds a ref on a context
+ * and the dispatch would mean that the context would hold a ref on the
+ * monitor. If someone stopped iterating the context at just this
+ * moment both the context and monitor would leak.
+ *
+ * Instead, we dispatch the context to itself. We don't hold a ref.
+ * There is the danger that the context will be destroyed during the
+ * dispatch, but if that is the case then we just won't receive our
+ * callback.
+ *
+ * When the dispatch occurs we just lookup the monitor in the hashtable,
+ * by context. We can now add and remove refs, since the context will
+ * have been acquired.
+ */
+
+typedef struct _GAppInfoMonitorClass GAppInfoMonitorClass;
+
+struct _GAppInfoMonitor
+{
+ GObject parent_instance;
+ GMainContext *context;
+};
+
+struct _GAppInfoMonitorClass
+{
+ GObjectClass parent_class;
+};
+
+static GHashTable *g_app_info_monitors;
+static GMutex g_app_info_monitor_lock;
+static guint g_app_info_monitor_changed_signal;
+
+G_DEFINE_TYPE (GAppInfoMonitor, g_app_info_monitor, G_TYPE_OBJECT)
+
+static void
+g_app_info_monitor_finalize (GObject *object)
+{
+ GAppInfoMonitor *monitor = G_APP_INFO_MONITOR (object);
+
+ g_mutex_lock (&g_app_info_monitor_lock);
+ g_hash_table_remove (g_app_info_monitors, monitor->context);
+ g_mutex_unlock (&g_app_info_monitor_lock);