[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
On Thu, 2004-09-02 at 22:04 -0700, Chris wrote:
> Yes, this is a bad idea and a possible source of the problem. Don't
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.
> forget, Allegro implicitly calls acquire_bitmap(screen) when you draw to
> the screen.. and since you can nest acquire_bitmap calls, the code will
> happily let two threads write to the screen at the same time.. which
> would be a nice source for Xlib async errors.
>
Actually, that never happened.. 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 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.
Evert: Did you try 4.1.15 on that multi-processor machine? I'd feel
better if it also fails :)
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 ?? ()
--
Elias Pschernig