不要阻塞tkinter的mainloop

2020年6月22日 / 204次阅读 / Last Modified 2020年6月22日
tkinter多线程

最近被GUI多线程代码的死锁问题搞的有点头大,本文总结一下自己的所思所得,并不代表完全正确,因为毕竟没有去阅读tk的源代码。

mainloop,故名思议,它就应该是python程序的mainThread。这个GUI的mainloop,靠事件响应驱动。比如有一个button(A),点A,就是给这个mainloop传递了一个事件,这个事件最后会传递到A绑定的commnad函数中去执行。

不要阻塞tkinter的mainloop,就是不要在事件响应的函数中阻塞住,否则GUI会卡死。常见的现象是,A绑定的函数执行需要那么一点点时间,点击下去后,GUI就会卡住那么一点点时间。所以,大多数编程教材都建议使用多线程来规避GUI的卡死,即点击A后启动一个线程,A绑定的函数立即返回,释放GUI(表示GUI有可能接收别的事件的响应了),具体工作由线程完成。

由线程来完成工作,并规避GUI的卡死,是个很好的最佳实践,不过,我遇到的问题是,线程被GUI卡死了!

计算模型大概是这样的:多个线程通过操作一个Text控件就是往里写log;写log的执行流程代码中,有mutex,用来多线程间控制Text的状态;GUI的事件响应中,也有mutex.acquire;只要GUI出发这个事件,整个程序就死锁了。

为什么会这样呢?我想来想去,觉得出问题的地方,就是线程被GUI卡死了。为什么线程会被卡死呢?因为线程在mutex.acquire中在向GUI发事件(操作Text),而此时GUI在等待mutex,于是死锁。

GUI在一个事件没有处理完的情况下,是无法处理别的事件的。比如我们在A的绑定函数中sleep,整个GUI上其它地方都点不了(OS会记录这些事件,在GUI被释放后再把这些事件灌给它)。线程中对Text的操作无法返回,很可能就是因为GUI已经被卡死了。

奇怪的是,如果A绑定代码中也操作Text,不会卡死,而只是在GUI被释放后,一口气把所有的log全显示出来,log显示的过程只是感觉不流畅而已。区别在于mainloop中触发事件和非mainloop中触发(我个人的理解哈),也许存在内部事件和外部事件这样的区别,外部事件会被阻塞,即线程操作Text的代码被阻塞,而mainloop中操作Text的代码,只是更新延后。

总之,在GUI中如果有mutex.acquire这样的代码,是非常危险的,一不留神就死锁。不要阻塞mainloop的事件响应,用线程是OK的,用户友好。多线程之间有mutex没问题,只要GUI的mainloop没有被卡死。

-- EOF --

本文链接:https://www.pynote.net/archives/2074

留言区

《不要阻塞tkinter的mainloop》有1条留言

电子邮件地址不会被公开。 必填项已用*标注

  • 麦新杰

    再次遇到线程被GUI卡死,这次是这样的:GUI事件向queue写入100条消息,但是queue的长度小于100,由于此时线程访问GUI资源被卡,消耗queue内容的线程不起作用,于是GUI就等待queue的空位置,结果卡死了... [回复]


前一篇:
后一篇:

More


©Copyright 麦新杰 Since 2019 Python笔记

go to top