GTK多线程访问界面

最近被GTK的界面死掉问题困扰。GTK本来就不是线程安全的,但是有些应用,确实需要有不止一个线程访问图形界面的问题。我查了很多资料,基本上都是说开gthread支持,然后在需要访问界面的代码前后加上gdk_threads_enter()和gdk_threads_leave()。

但是很不幸,在我的实践中,这样的界面会在不确定的死掉。虽然,从逻辑上来说,这样做是合理的。我并不知道是为什么,

现在也没有时间去看gtk+的实现代码。只能临时找到一个解决方案,就是使用gtk_add_idle函数,添加一个刷新任务。

大致就是

gboolean refresh_ui(gpointer data)

{

//refresh operations

return FALSE;

}

…….

gtk_add_idle(refresh_ui, data);

目前使用中没有问题,现在先记下来,回头在有时间再研究为什么。

《GTK多线程访问界面》有7条评论

  1. 的确,我也碰到跟楼主一样的问题,不得已也是通过g_idle_add来解决的,根据经验,对于比较简单的例子用gdk_threads_enter倒也没问题,我的程序中潜入了一个浏览器,用gdk_threads_enter貌似不行

    回复
  2. 恩,写得很详尽,谢谢!
    其实,gtk_idle_add()的原理就是手动地使程序回到main loop中,是这样吧?
    我猜gtk_idle_add()比gdk_threads_enter()更有效的原因是,gtk_idle_add()是程序员手动指定,交给main loop控制执行的,每次遇到gtk_idle_add()的时候,总能够把所有的刷新任务执行完,而且,不用考虑mutex是否锁定。 而gdk_threads_enter()则由内核控制,且在刷新数据时受到mutex的影响,如果你设定的mutex lock不当,那么新的线程在设定mutex lock时就会阻塞。 你把GUI和数据绑到一起,使用gtk_idle_add()确实要安全得多,不过理论上讲也比threads更耗资源。
    没有见过——也不可能见到你的代码,权且这样瞎猜一下。

    回复
  3. to Kermit:
    抱歉,是我手误了,估计你搜到的也是别人写错了。因为gthread支持属于glib库对thread的封装,故初始化线程环境等对线程环境设置的函数是g_thread_,比如,g_thread_init(),但是这两个进入界面访问的临界去的函数是属于gdk库的,因为到了图形一层就是属于gdk支持的内容了,这两个函数名我已经改成正确的了gdk_threads_enter()和gdk_threads_leave()。gdk中对线程的支持是用gdk_threads_打头的。
    另外,事实上,gtk+中主消息循环gtk_main()是一定要维护界面的,而且贯穿整个程序的生命周期,事实上用gtk_idle_add()和gtk_timeout_add()这样的函数,就是在主循环中去访问界面,也间接的让只有主循环所在的线程去访问界面,所以要比使用gdk_threads_enter()和gdk_threads_leave()直接去访问界面稳定性要好一些,至少我目前的经验是这样。

    回复
  4. 恩,我理解你说的,MVC在某些时候所带来的通信成本确实很大,尤其是当用户需要直接在视图上跟这些数据交互时(如Excel表格那种)。

    还有个问题,老大,g_thread_enter()和g_thread_leave()我搜到有人在用,但为什么我在官方的文档和主页上找不到呢?

    回复
  5. to luguo:
    哈哈,就是这么假~

    to Kermit:
    事实上,你说的是可以的,MVC设计模式就是一种,将数据的存储和表示分开。但是有时候设计是比较复杂的。在嵌入式系统上,而且往往受到硬件资源和成本的限制,在数据量巨大的时候,通信成本也是比较高的,往往造成整体成本上升。不过你的思路是对的,只是实现的时候往往需要对成本和其他一些事情作出妥协。程序设计,就是妥协的艺术~所以,就这样了~

    回复
  6. “有些应用,确实需要有不止一个线程访问图形界面的问题。”
    请教个问题:能否通过一些设计上的改良,让GUI与线程控制无关? 我觉得线程是程序的功能部分,而GUI不过是个视图而已,按理说应该可以分开吧。
    (注:我是提问的,不是提建议的;p)

    回复

回复 Kermit 取消回复

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据