Re: [GtkGLExt] driving rendering with signals

[Braden McDaniel <braden endoframe com>]

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 <braden endoframe com>