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
