> 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? _______________________________________________ xorg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xorg
