driving rendering with signals
|
View:
New views
5 Messages
—
Rating Filter:
Alert me
|
 |
driving rendering with signals
by Wesley Smith
::
Rate this Message:
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? thanks, wes _______________________________________________ gtkglext-list mailing list gtkglext-list@... http://mail.gnome.org/mailman/listinfo/gtkglext-list |
|
|
Re: driving rendering with signals
by Braden McDaniel
::
Rate this Message:
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@...> <http://endoframe.com> Jabber: <braden@...> _______________________________________________ gtkglext-list mailing list gtkglext-list@... http://mail.gnome.org/mailman/listinfo/gtkglext-list |
|
|
Re: driving rendering with signals
by Wesley Smith
::
Rate this Message:
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@...> 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@...> > <http://endoframe.com> Jabber: <braden@...> > _______________________________________________ > gtkglext-list mailing list > gtkglext-list@... > http://mail.gnome.org/mailman/listinfo/gtkglext-list > gtkglext-list mailing list gtkglext-list@... http://mail.gnome.org/mailman/listinfo/gtkglext-list |
|
|
Re: driving rendering with signals
by Braden McDaniel
::
Rate this Message:
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@...> _______________________________________________ gtkglext-list mailing list gtkglext-list@... http://mail.gnome.org/mailman/listinfo/gtkglext-list |
|
|
|
| Free embeddable forum powered by Nabble | Forum Help |
