On Jun 12, 2012, at 5:48 PM, Peter Hutterer <[email protected]> wrote:
> On Tue, Jun 12, 2012 at 05:11:49PM -0700, Andy Ritger wrote: >> ... >> Making the 'event' variable in mieqProcessInputEvents() non-static >> avoids the FatalError() in FixKeyState(), but is it problematic to >> have the re-entered instance of mieqProcessInputEvents() process events >> from miEventQueue before the first instance of mieqProcessInputEvents() >> has completed processing of its current event? > > good analysis, thanks. afaict we need a mutex in > mieqProcessInputEvents(), it's certainly not designed to be reentrant and > it's pointless anyway - if you're already processing events, why would you > need to do so again? FWIW, XQuartz does have a mutex in mieqProcessInputEvents, and I haven't had any reports of deadlock, so my guess is that DIX doesn't re-enter mieqProcessInputEvents for most cases. This UpdateCurrentTime() case is certainly worrisome. Should RRTellChanged be calling UpdateCurrentTimeIf() instead of UpdateCurrentTime()? Is there a way we can make this API more robust rather than just adding assertions to the implementation? For example, why does UpdateCurrentTime need to ProcessInputEvents? _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
