[PATCH 2/4] X event queue mutex

[Simon Thum]

> On Fri, 2008-10-03 at 05:57 +0300, Daniel Stone wrote:
>> Except if the lock is held across the entire event processing, because
>> we need to queue events from event processing.
I guess that's what I meant with guaranteeing order.
> 
> That makes it more important that the mutex cover precisely the values
> which will be modified in multiple threads, inserting events into the
> queue, and not pulling them out, which is done only in a single thread.
Fine so far.

But how do we touch structures which the IT uses before enqueuing
from the main thread? E.g. with input properties, you're likely to 
modify IT-relevant data. I guess that's mostly a single write so 
visibility won't hurt much anyway, but there might be more complex ops. 
This should be considered a no-go or we need means to cope with it.

A possiblity would be to lock the queue while processing prop handlers 
so the unlock guarantees visiblity, but this still doesn't provide a 
100%-fix for data races.

Opinions?