> From: Adam Jackson <[email protected]> > Date: Thu, 16 Dec 2010 10:32:21 -0500 > > On Wed, 2010-12-15 at 23:08 +0100, Mark Kettenis wrote: > > > Yes, that is the additional locking that's necessary. I'd say you'll > > need a mutex that you lock in x86BlockSIGIO() and unlock in > > xf86UnblockSIGIO() and lock/unlock around each event that you process > > in the input thread. > > It's more subtle than that. BlockSIGIO is used to mean both "suppress > input because I'm changing the input state", and "suppress signals > because I don't want my usleep()s to wake up early". So you really need > as a first pass to change the callers to say what they mean, and the > former case should be xf86BlockInput (which then happens to call > BlockSIGIO for now, but turns into a mutex in the threading change).
BlockSIGIO is also used to "suppress silken mouse because I'm messing with the graphics hardware state". Of course "suppress input" has "suppress silken mouse" as a side-effect, but it is something to keep in mind as well. _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
