RE: [AD] race condition in X11

[Elias Pschernig <elias@xxxxxxxxxx>]

On Mon, 2005-11-28 at 14:33 +0000, Vincent Penecherc'h wrote:
> It actually does a weird thing: there's an automatic unlock
> after a "complex" operation. That has to be intended...
> The release op (it's not unacquire, sorry, just looked up the
> name) doesn't do anything, so even if it doesn't keep track
> of nesting, it seems proofed against nesting mismatch, though
> I don't see the interest of doing this, since I thought the
> point of it was to tell Allegro when you were doing batch ops
> so it could setup the hardware to be faster. But then that's
> just what I recall from a few years ago, and I could be wrong
> (again).
> 

Some notes about what I remember:

Under X11, an X11 lock is is used to always make sure that only one
thread accesses any X11 function, or you get one of those "X async
reply" crashes. Now, since all access to screen needs to acquire that
lock, it double functions as lock used by acquire_screen - there's no
extra lock for that.

Now, the mouse drawer does something which should be familiar to anyone
having studied CS: It acquires two locks, the X11 one, and some timer
lock. So, it's easy to do something to make it deadlock, like manually
acquiring the X11 lock from the main thread with acquire_bitmap, then
trying to obtain the same lock from the timer thread :P

In short, avoid the software mouse drawer at all costs - Allegro's gfx
system is made to only work from one single thread (just think about all
the state contained in a BITMAP, e.g. clipping state), but the mouse
drawer draws from the timer thread, so it never will work correct (you
might disable clipping in the main thread, then the software mouse is
drawn from the timer, or things like that..), and even wose, it will
always be likely to deadlock if you're not careful.

-- 
Elias Pschernig