Re: Help needed with an a11y related Cheese bug
- From: Filippo Argiolas <fargiolas gnome org>
- To: michael meeks novell com
- Cc: cheese-list gnome org, gnome-accessibility-list gnome org
- Subject: Re: Help needed with an a11y related Cheese bug
- Date: Thu, 5 Mar 2009 17:24:43 +0100
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]