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
