Re: [AD] XIM patch for Allegro 4.1.x

[Chris <chris.kcat@xxxxxxxxxx>]

Elias Pschernig wrote:
> No, that should produce an async error AFAIK. What I was doing was
> different. The input thread gets the X11 keyboard event, and calls the
> add_key or similiar function in keyboard.c. This calls the user
> keyboard callback. Now in this callback, I was drawing the box of the
> pressed key. Because it didn't deadlock immediately, the locks must be
> nestable.. so this just did the gfx calls, then returned. The input
> thread's X11 lock was held all the time.

Yeah. I took a look at the locking stuff again, and to my surprise, 
looks quite different than how I had it. I'm not sure, but I fon't 
really like how it looks.. I can't place my finger on it, but something 
bugs me about it.

Anyway, it appears that yes, the locks are nestable within a thread. So 
what's happening is:

* Lock input thread
* For each key event
  * Read from X and send to Allegro's kb handler
  * Call kb handler callback
* Unlock input thread

And you were doing drawing in the kb callback, so you were getting input 
and drawing at the "same time".

> The main thread should simply have blocked on its gfx calls - but
> yeah, I think some drawing commands don't do proper locking. I think,
> for testing, we should have a "disable direct update" config setting,
> which disables the direct calls to X11 drawing primitives. Then we
> could compare if the crash persists without that.

In this case, the functions not locking properly wouldn't have made a 
difference. Since they were being called on a thread with the lock 
already in place, it simply would've passed through without even 
attempting to lock again.

And we already have a "disable direct update" setting for DirectDraw. It 
shouldn't be hard to extend that to X, either. I'll try and work on a 
patch to do that.