On Thu, Mar 5, 2009 at 4:59 PM, Michael Meeks <[email protected]> wrote: > If you are using gtk+ from multiple threads -all- instances of gtk+ use > need to be safely protected with GDK_THREADS_ENTER / LEAVE.
Ok >> Furthermore if I try to add >> some gdk_threads_enter/leave here and there they block the application > > here and there ? :-) it is a non-recursive mutex: you need to add it > only for idle handlers - but then using the gdk_threads_add_idle type > calls - that is then done for you. > >> when a photo is taken (probably that's the effect of gdk_threads_enter >> if you're already in the main thread). > > Surely, you know when a photo is taken if you are using gtk+ already, > and hence whether the mutex has been taken for you by the gtk+ event > dispatch or not ? :-) > > In particular are you doing: > > gdk_threads_enter(); > gtk_main(); > gdk_threads_leave(); Sure. And I'm almost sure that cheese_flash_fire (the function that calls the faulty g_timeout_add) is called by a signal handler (the button-clicked signal) and it is run within the main loop. So the lock has been already done by those 3 lines. So, if I understood it correctly, I have to protect gtk calls when I'm not in the main loop and within generic callbacks. And, if I didn't miss anything looking in the sourcecode, that's what we're doing already. The only thing that we should do is to use gdk_threads_add_timeout instead of g_timeout_add.. but as I said it doesn't fix this particular problem. > It's well worth reading the gtk+ FAQ on this I think. Thanks, I was just reading it when I received your reply :-P _______________________________________________ gnome-accessibility-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
