Re: [GtkGLExt] driving rendering with signals
- From: Wesley Smith <wesley hoke gmail com>
- To: Braden McDaniel <braden endoframe com>
- Cc: gtkglext-list gnome org
- Subject: Re: [GtkGLExt] driving rendering with signals
- Date: Mon, 18 May 2009 10:35:56 -0700
I don't think I'm using more than one thread unless I'm
misunderstanding UNIX signals. It's more the case of reentrancy than
thread safety. Here's the relevant chunk from the backtrace:
#16 0xb7d21463 in luaav::Notifier<luaav::Clock>::notifyObservers (
this=0x9ede600)
at /home/whsmith/Documents/LLVMAV/mergathon/bin/../LuaAV/library/include/LuaAVUtility.h:46
#17 0xb7d1fafc in luaav::Clock::tick (this=0x9ede600)
at /home/whsmith/Documents/LLVMAV/mergathon/bin/../LuaAV/library/src/LuaAVClock.cpp:53
#18 0xb7d6340d in tick (signo=14)
at /home/whsmith/Documents/LLVMAV/mergathon/bin/../LuaAV/library/linux/LuaAVLinuxClock.cpp:62
#19 <signal handler called>
#20 0xb7f42430 in __kernel_vsyscall ()
#21 0xb7682dbd in select () from /lib/tls/i686/cmov/libc.so.6
#22 0xb6246e5f in ?? () from /usr/lib/libxcb.so.1
#23 0xb6248862 in xcb_wait_for_reply () from /usr/lib/libxcb.so.1
#24 0xb65ae369 in _XReply () from /usr/lib/libX11.so.6
#25 0xb65a1667 in XSync () from /usr/lib/libX11.so.6
#26 0xb7eb86b1 in glXWaitX () from /usr/lib/libGL.so.1
#27 0xbfe408f8 in ?? ()
Notice that there's a call to glXWaitX and then a signal handler
interrupt, which will eventually lead to another glXWaitX call,
causing deadlock.
wes
On Mon, May 18, 2009 at 10:31 AM, Braden McDaniel <braden endoframe com> wrote:
> On 5/18/09 1:22 PM, Wesley Smith wrote:
>>
>> As I'm trying to integrate gtkgl into my app, I'm running into
>> problems with deadlock in pthreads. From the looks of it, these libs
>> aren't reentrant as I'm getting lots of stalls with backtraces that
>> look like: http://www.mat.ucsb.edu/whsmith/temp/gdb.txt . Ideally,
>> I'd like to drive everything from my own timer, but sometimes it
>> overtakes GtkGL's rendering/querying. Is there any way around this or
>> am I forced to use glib timers?
>
> GTK+ itself does not support concurrent use by more than one thread. This is
> a pretty good write-up of the issues:
>
>>
>> http://blogs.operationaldynamics.com/andrew/software/gnome-desktop/gtk-thread-awareness.html
>
> I'm pretty sure GtkGLExt just requires consistency with GTK+'s rules. If you
> think you're applying those rules correctly and you're still having
> problems, please explain a bit more about exactly what you're doing.
>
> --
> Braden McDaniel e-mail: <braden endoframe com>
> <http://endoframe.com> Jabber: <braden jabber org>
> _______________________________________________
> gtkglext-list mailing list
> gtkglext-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtkglext-list
>
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]