[PATCH 2/4] X event queue mutex

[Tiago Vignatti]

Hey Jeremy, I'm going well. Thanks my friend.

Jeremy Huddleston escreveu:
> I hope things are going well for you.  I've recently hit an issue using 
> locks in miEq.  We're doing it the same way in mieq.c as your proposal 
> (patch 2/4) and this causes us to hit a deadlock when the enqueueing 
> thread is waiting for the lock to push an event and the dequeuing thread 
> (the server thread) is processing an event that requires a message to be 
> sent to the enqueueing thread.

I posted another version of that patch that doesn't requires a lock in 
mieqProcessInputEvents().

We just need to guarantee order of events enqueued (to protect writes to 
the tail pointer in mieqEnqueue) and don't need to serialize dequeuing 
events. So no locks in the server thread is needed.

(well, this is the theory of the X server with Xorg DDX and the input 
thread craziness. Maybe your problem is a bit different from mine)


> I am going to try solving this by making the lock a bit more 
> conservative in mieqProcessInputEvents.  Our current implementation 
> (we're still on 1.4) passes the event to the handler as a pointer to the 
> event within the queue.  In 1.5, mieqProcessInputEvents now copies the 
> nevents first... so we might be able to release that a bit sooner...
> 
> The thing is that we have:
> 
> e = &miEventQueue.events[miEventQueue.head];
> 
> Then e->events is copied, but 'e' itself is still directly referenced 
> throughout mieqProcessInputEvents.  Could we actually just copy all of 
> miEventQueue.events[miEventQueue.head] to a local copy and release the 
> lock after that? I see us using:
> 
> e->pDev
> e->nevents
> e->events (already copied in 1.5.x and later if nevents > 1)

I'm failing to see a reason to carry a pointer to the input queue here. 
It seems plausible. Peter do you have any thoughts?


Cheers,

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