2017-07-04 3 views
3

My gtk3アプリケーションは、GUIまたはデーモンモードで実行できます。デーモンモードを実現するために、私はg_application_hold()を使います。gtk3 - g_application_hold()中のログアウト

これまでのところ素晴らしいですが、デーモンモードでアプリケーションを実行している間にセッションからログアウトすると、OSがkillするまでシステムが8秒間フリーズします。同様に、私のクリーンなシャットダウン手順は実行されません。 GUIモード中ではなく、デーモンでのみ発生します。

は現在、私はセッションのログアウトを実現するために使用することができ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方法がありますか?

+1

UIがある場合はGtkが意味を持ち、そうでない場合はGLib関数をチェックします。 UIを分離させるためにロジックを分離してみてください。 –

+1

@JoséFonteこの場合、アプリケーション(XfceのThunar)はデーモンとして起動し、最後のウィンドウが閉じていても、さらに初期化を高速化し、ファイル転送を処理します。 gtk2バージョンではうまく動作しますが、gtk3/GApplication/gdbusへの移行後にこの副作用が始まりました。 – AndreLDM

+1

まあ、g_application_hold/releaseはg_object_ref/unrefのように少し動いています。シグナル(os)を使用する場合、アプリケーションは* unixのみでなければなりません。glibのunix関数を使用してください:[g_unix_signal_add/add_full](https://developer.gnome.org/glib/stable/glib-UNIX-specific-utilities-and- integration.html)。なぜUIがフリーズするのかわからない。 –

答えて

0

最後に、私はこの奇妙な動作の理由を知っています。これはセッションマネージャによってトリガーされた直接gtk_main_quit()によって引き起こされました。

g_application_release(..).が1行前に実行された場合、ログアウト遅延はもうありません。

は実際にも、Gtkの-CRITICALこの gtk_main_quit()によってトリガました:セッション・マネージャは、すでに所有しているコンソールを閉じているので、今、私はちょうどメッセージを見ていない

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

ティル。

関連する問題