gtk3 - 在 g_application_hold() 期间注销答案

【问题标题】：gtk3 - logout during g_application_hold()gtk3 - 在 g_application_hold() 期间注销
【发布时间】：2017-07-04 21:02:20
【问题描述】：

我的 gtk3 应用程序既可以在 GUI 中运行，也可以在守护程序模式下运行。为了实现daemon-mode，我使用g_application_hold()。

到目前为止，这很好用，但是一旦我在守护程序模式下运行应用程序时从会话中注销，我的系统就会冻结 8 秒，直到操作系统将其杀死。就像我的干净关机程序没有执行一样。这只发生在守护进程中，而不是在 GUI 模式下。

目前我通过hook SIGHUP信号解决了这个问题，可以用来实现会话注销：

static void
handle_hangup_signal (int signal)
{
  MyApplication     *application = my_application_get ();
  g_application_release (G_APPLICATION (application));
}
...
signal(SIGHUP, handle_hangup_signal);

这修复了我的错误。没有 8 秒的延迟，我的干净关机被执行了。

但是我想知道是否有更干净的 gtk3 解决方案？使用 g_application_hold() 可以吗，还是有更好的 gtk3 方式在 daemon-mode 下启动某些东西？

【问题讨论】：

当有 UI 时 Gtk 才有意义，如果没有则检查 GLib 函数。尝试分离逻辑以使 UI 分离。
@JoséFonte 在这种情况下，应用程序（Xfce 的 Thunar）作为守护进程启动，以加快进一步的初始化并处理文件传输，即使在最后一个窗口关闭时也是如此。它在 gtk2 版本中运行良好，但在迁移到 gtk3/GApplication/gdbus 后，这种副作用就开始了。
嗯，g_application_hold/release 的行为有点像 g_object_ref/unref。如果使用信号 (os)，那么应用程序必须是 *unix，使用 glib 的 unix 函数：g_unix_signal_add/add_full。不知道为什么 UI 冻结。
这是一个很好的提示，我将尝试 g_unix_signal_add/add_full。非常感谢！（刚刚意识到我当前的信号处理程序与 gtk 自己的线程完全异步调用，这可能会引起一些麻烦）

标签： signals daemon gtk3 logout

【解决方案1】：

我终于知道了这种奇怪行为的原因。它是由会话管理器触发的直接gtk_main_quit() 引起的。

如果g_application_release(..).在前一行执行，则不再有注销延迟。

实际上，这个gtk_main_quit() 甚至触发了 Gtk-CRITICAL：

Gtk-CRITICAL **: gtk_main_quit: assertion 'main_loops != NULL' failed

到目前为止，我还没有看到该消息，因为会话管理器已经关闭了拥有的控制台。

【讨论】：