On Mon, 2009-05-18 at 10:35 -0700, Wesley Smith wrote: > 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.
Ah, I see what you're doing. I'm really not sure how X11/GLX are supposed to behave in such a scenario; and a bit of Googling hasn't gotten me anywhere. The Mesa mailing list would presumably be a good place to ask about how GLX should behave. Though, I wouldn't really be surprised if this can't be expected to work reliably. As far as GTK+ is concerned, I suspect you're better off having your signal handler trigger the addition of a callback that the GTK+ main loop can service. -- Braden McDaniel <[email protected]> _______________________________________________ gtkglext-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtkglext-list
