Le 26/04/2013 03:59, Kip Warner a écrit : > On Sat, 2013-04-20 at 18:54 +0200, Colomban Wendling wrote: >> Just never do something time consuming in the main loop thread. If you >> don't there should not be any lag. > > Hey Colomban. The time consuming task is in its own separate thread, but > it's making a GIF animation lag and user interface responsiveness as > well.
That's weird. However, although I don't know much about Python threading (and another guy in this thread suggests it's not really good), I'm wondering whether your thread couldn't be simply locking stuff used by both GUI and worker thread, effectively blocking the GUI one. For example, your idle callback _updateGUI() uses the thread's self, so I guess Python would lock it. And this would mean that the callback and the thread functions could not run concurrently. And even worse, if the Python thread model is based on simple functions locks (e.g. the lock is held at the function entrance, and only released on function leaving), this would mean the callback could never run before the thread as finished. I don't know, but this is an idea from where the issue might come from. BTW, in VerificationThread.run, which I believe is run in the thread, right?, there are access to GTK widgets (self._assistant). This either requires a lock (which may be the reason why your thread would block the main one), or it may crash (since GTK is NOT thread safe). Anyway, I think this should rather be done in the idle callback. BTW, you actually mark the page as complete in both run() and _setQuitOk() which is called by run(). > [...] > >>> I could have tried this aforementioned event pump from outside the >>> updateGUI callback and done it from within the worker thread, but I >>> didn't know if that was thread safe to do. >> >> I think the main loop is completely thread safe, event with this, but >> again *do not do this*. If the even loop freezes, it's that you do too >> much work in it's thread, nothing else. Check what you do in the main >> thread and that takes time, and try either optimizing it or movie it to >> another thread. > > I think what I'll have to do is try optimizing the thread to give the > event pipeline a chance to "breath", but then that still begs the > question of the best way to do that. I thought of manually flushing the > event queue, but I don't think you can do that from the worker thread > and you mentioned it is not a good idea to do even if you could. I don't think optimizing the worker thread is the solution for the GUI issue. If everything worked as it should, the worker thread could take as much time as it wanted, and it still wouldn't block the main thread. That's the point of threads: doing tasks in parallel. Of course reducing the time the worker thread takes would reduce the UI freeze duration, but it wouldn't solve it. However, if most of your thread's time is lost in IO rather than computation time (e.g. if the MD5 runs faster than the IO), you could perhaps avoid a thread using asynchronous IO calls and computing the sum by packets. Something like this (in Vala pseudo-code): async string sum(File file) { var sum = new MD5(); while (true) { /* read by blocks of 2048 bytes (or whatever) */ var data = yield file.read_async(2048); if (data) { sum.push(data); } else { break; } } return sum.hash(); } Here yield would work like in Vala, which basically means calling a implicit callback which will perform the following instructions when the asynchronous work is done. But this doesn't explain why your program blocks the main thread, and may very well not be practical in your case (or even, on Python, I don't know). Hope this could help in some way. Regards, Colomban _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list