[PATCH 2/4] X event queue mutex

[Tiago Vignatti]

Hi Jeremy,

Jeremy Huddleston escreveu:
> Well the problem was that mieqProcessInputEvents DOESN'T use those 
> locks, so it can read the incremented value of miEventQueue.tail 
> thinking that the item at head=tail-1 is ready to read when in fact 
> mieqEnqueue is still in the process of writing to it.
 >
> Further, mieqEnqueue sometimes edits miEventQueue.tail-1 (when the 
> current and tail-1 events are MotionNotify)... but 
> mieqProcessInputEvents is already reading it.

yeah. Now your last patch makes more sense to me (but not that first hunk).


> For this reason, I went back to locking inside mieqProcessInputEvents 
> with XQUARTZ.

Your mutex will lags your cursor update on screen because the input 
thread will block before enqueuing while the main thread pops events. On 
this case try to keep the lock near the critical region on mieqPIE, 
avoiding coarse grained locking.


Cheers,

PS: this problem of the event queue being processed by more then one 
user shows how multi-threaded applications suck so much to program. 
Moreover, if you try to use gdb to debug then you'll see the crazy world 
that we're living.

-- 
Tiago Vignatti
C3SL - Centro de Computação Científica e Software Livre
www.c3sl.ufpr.br