[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
Elias Pschernig wrote:
Yes, you're right. Not drawing from different threads fixes it. But it
makes it more complicated, I added a ringbuffer to which the gfx
commands from one thread along with their parameters are saved, and the
main thread polls that buffer and executes the drawing commands. We
really need to expose a simple locking API. al_lock, al_unlock, al_wait,
al_signal. That should do. It would make drawing from 2 threads (in my
particular case, a timer callback - so I actually wasn't using any
additional threading lib) easy - just put the drawing in both threads
inside al_lock/al_unlock.
Another possiblity would be to make acquire/release_bitmap be
thread-aware. Though I'd need to find out how to get some kind of thread
index so I can match it up with future acquire attempts.
the event thread blocked on XLockDisplay(), and the main thread on the
> first X11 gfx call, in this case XSetForeground() - the result, a
> classic deadlock.
I'm not sure I follow. If the event/bg manager thread calls
XLockDisplay, any future attempts to _xwin_lock/acquire_screen would
block until the event thread calls XUnlockDisplay.
I'm not really sure this is supposed to happen, after
> all it worked just fine without that change.. but if it speeds up X11
> drawing, I guess it is ok. All programs drawing inside timers will
> lock up in X11 now though (which they did not before) - we should
> check this doesn't happen internally in Allegro in certain
> circumstances, e.g. maybe the mouse drawing.
Yeah, I was concerned about the mouse drawing with my _xwin_(un)lock
patch, but I didn't run into any problems.. and the only lockups I've
ever gotten were when the mouse wasn't visible.
Though it that is the case, hopefully making acquire/release_bitmap
thread-aware will fix the problem.
gdb shows this:
(gdb) bt
#0 0x40055115 in pthread_cond_wait@xxxxxxxxxx ()
from /lib/tls/libpthread.so.0
#1 0x400cc286 in _XUnregisterFilter () from /usr/X11R6/lib/libX11.so.6
#2 0x400cc485 in _XUnregisterFilter () from /usr/X11R6/lib/libX11.so.6
#3 0x400a94e5 in XSetForeground () from /usr/X11R6/lib/libX11.so.6
#4 0x080c2c3e in _xwin_rectfill (dst=0x82050e8, dx1=9, dy1=393, dx2=10,
dy2=407, color=16711935) at src/x/xvtable.c:375
#5 0x08076044 in rectfill (bmp=0x82050e8, x1=9, y1=393, x2=10, y2=407,
color=16711935) at draw.inl:77
#6 0x08058da7 in draw_progress_bar (pos=1, len=184) at almid.c:80
#7 0x08059a6d in main (argc_=21, argv_=0xbffff664) at almid.c:371
(gdb) thread 2
[Switching to thread 2 (Thread 1087085488 (LWP 12888))]#0 0x40055115 in
pthread_cond_wait@xxxxxxxxxx () from /lib/tls/libpthread.so.0
(gdb) bt
#0 0x40055115 in pthread_cond_wait@xxxxxxxxxx ()
from /lib/tls/libpthread.so.0
#1 0x400cc286 in _XUnregisterFilter () from /usr/X11R6/lib/libX11.so.6
#2 0x400cc485 in _XUnregisterFilter () from /usr/X11R6/lib/libX11.so.6
#3 0x400cca75 in XLockDisplay () from /usr/X11R6/lib/libX11.so.6
#4 0x080a3c2a in _xwin_handle_input () at src/x/xwin.c:2437
#5 0x0809d8ba in _xwin_bg_handler (threaded=1) at src/x/xsystem.c:154
#6 0x080bfb70 in bg_man_pthreads_threadfunc (arg=0x0)
at src/unix/uthreads.c:100
#7 0x400529b4 in start_thread () from /lib/tls/libpthread.so.0
#8 0x00000000 in ?? ()
I'm not sure what to make of this.. which thread did it die in?
- Kitty Cat