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

[Peter Wang <tjaden@xxxxxxxxxx>]

Chris wrote:

> On Tue, 26 Oct 2004 00:47:54 +0200, Elias Pschernig <elias@xxxxxxxxxx> wrote:
>  
>
> > After finally realizing that two displays won't easily work with
> > Allegro, I just took the simple approach of using a pthreads lock
> > instead of XLock. Why didn't anyone tell me earlier? :)
> >    
>
> I'm not sure I like this. If it was just this simple of replacing
> XLock with pthreads lock, why create the XLock in the first place? For
> all we know, the XLock can (and probably does) do more than just a
> thread lock, since Xlib isn't allowed to even have two calls from
> seperate contexts in the same thread. XLock probably does some queue
> flushing when needed (as shown by the blit test problem in the test
> program).
>  

I looked at the code for XLock and AFAICT it doesn't (not that I 
understand the Xlib code, but I didn't see any call, direct or 
otherwise, from XLock/UnlockDisplay to XFlush).  It does try to do some 
more than what a pthread_mutex_lock() would do though.

> I think something like this really needs to be investigated deeply..
> to find out what the expected behavior of XLock and XUnlock are, how
> they deal on different systems (multi-cpu, non-x86, etc), and so on.
> We wouldn't want to do this now and all of a sudden notice problems in
> 4.2 and not know why.
>  

I guess it just comes down to how much testing we can fit in.

> > The timer wants to draw the mouse, so waits for the
> > mutex of vsync (called by e.g. set_palette). But vsync waits for the
> > timer value to change :P Not sure why it caused no problems with X
> > locking.
> >    
>
> The mouse draw routine wants to (re)set the palette? I'll have to check that.
>  

I think he means like this:

1. The main thread calls set_palette, so grabs the lock.  Now 
set_palette waits for a vsync.  Under X vsync() is emulated using the 
retrace_count variable (it just waits for it to increment by one).

2. The timer thread kicks in and wants to draw the mouse.  It requests 
the lock.  But incrementing the retrace_count is the timer thread's job, 
but it's waiting for the lock held by the main thread.  Hence, deadlock.

Peter