Re: Help needed with an a11y related Cheese bug



On Thu, Mar 5, 2009 at 4:59 PM, Michael Meeks <michael meeks novell com> 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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]