Re: Deadlock/Freeze
Matteo Landi wrote: From the FAQ entry [1] it seems I need to enter/leave threads inside each timeout callback. Could the procedure described be a valid solution for my problem? Yes I believe you need to call enter/leave around calls to any gtk or gdk call inside the callback. You might also consider the g_idle_add pattern and have threads use this mechanisms to run callbacks in the main GUI thread, avoiding the locking issues entirely and also making your program more cross-platform. http://irrepupavel.com/documents/gtk/gtk_threads.html explains this pattern somewhat. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Deadlock/Freeze
Michael Torrie wrote: Matteo Landi wrote: From the FAQ entry [1] it seems I need to enter/leave threads inside each timeout callback. Could the procedure described be a valid solution for my problem? Yes I believe you need to call enter/leave around calls to any gtk or gdk call inside the callback. Not sure if this has to be done in the main thread or just the callbacks, though... ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Deadlock/Freeze
It is sad to say, but the issue described above, seemed to be generated by an human dumb error (as always). I have set two refresh times: one in the case of full connectivity (about an hour), and the other, smaller (1 minute), in the case of lack of communication. In order to implement this i did: def callback(): data = parse() if not data: gobject.timeout_add(1m, callback) else: gobject.timeout_add(1h, callback) return True As you can notice by yourselves, I forgotten to remove the return True, so it ended not in a so called deadlock, but in a sort of dos, because of the amount of thenumber of callbacks being wainiting in the main loop. So I changed return True, with a return False, and it seems to work properly (at least for the testing till now : ). Now it lasts the question about placing a threads_enter/leave in each callback. Is this really needed? I think that when the gstreamer threads wants to write on the screen, it insert an expose event from the main_loop, so the whole drawing is right handled from the main loop. These are just suppositions. On Thu, Oct 29, 2009 at 7:08 PM, Michael Torrie torr...@gmail.com wrote: Michael Torrie wrote: Matteo Landi wrote: From the FAQ entry [1] it seems I need to enter/leave threads inside each timeout callback. Could the procedure described be a valid solution for my problem? Yes I believe you need to call enter/leave around calls to any gtk or gdk call inside the callback. Not sure if this has to be done in the main thread or just the callbacks, though... ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list -- Matteo Landi http://www.matteolandi.net/ ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Deadlock/Freeze
Hi all, I'm working on an application used for displaying news (taken from internet) and spot-movies (using gstreamer). In the short term usage, everything is ok, but when I leave the application running for several hours, it ends freezing. How is it possible to create deadlock? In theory everything should be serialized in the gtk main loop, so there would not be any concurrency at all. The only thing that leaves me in doubts, is the interaction with gstreamer, even thought I called gobject.threads_init() before the gtk.main_loop() callback. From the FAQ entry [1] it seems I need to enter/leave threads inside each timeout callback. Could the procedure described be a valid solution for my problem? Thanks in advance. [1] http://faq.pygtk.org/index.py?req=editfile=faq20.015.htp -- Matteo Landi http://www.matteolandi.net/ ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
