Question

在我的GTK +应用程序中，GtkFileChooserWidget的实例是永久可见的。通过选择文件（单击），用户可以处理文件。这是由回调函数switch_file（）完成的。

g_signal_connect (chooser, "selection-changed", G_CALLBACK (switch_file), gs);

函数switch_file（）有时很慢，因为它在模态对话框中等待用户响应。除非删除当前在FileChooser中选择的文件（由应用程序本身或系统上的任何其他进程），否则一切正常。 FileChooser显然在自己的线程中运行，然后提交对switch_file（）的辅助调用，这会导致混乱。我尝试使用互斥锁阻止多次调用：

static void switch_file (GtkWidget *widget, gpointer data)
{
   info_t *gs = data;
   int err;

   if ((err = pthread_mutex_lock (&gs->mutex)))
      DebugExit ("pthread_mutex_lock(): %s", strerror (err));

   /* ... */
}

但是，对回调函数的所有调用都在同一堆栈的同一个线程内完成。因此，第二次调用pthread_mutex_lock（）失败（使用PTHREAD_MUTEX_ERRORCHECK_NP）并让进程退出。

当switch_file（）工作时，是否有可能推迟对回调函数的调用？对于用户事件（按键），它已经可以工作，但不能用于删除文件并行引起的信号。

如果信号无法推迟：收集所有选定文件并随后处理它们（在主线程内）的信号安全解决方案是什么？

Answer 1

我发现最好的解决方案是忽略信号。我不确定以下解决方案是否绝对安全但是有效。

static int switch_ignore = false;

static void switch_file (GtkWidget *widget, gpointer data)
{
   info_t *gs = data;

   if (switch_ignore)
      return;

   switch_ignore = true;

   /* Do some work on the file system. */

   switch_ignore = false;
}

Linux上的C语言中的GTK + 3.0：通过信号

1 个答案: