reentrancy of mieqProcessInputEvents()?

[Jeremy Huddleston]

On Jun 12, 2012, at 5:48 PM, Peter Hutterer <peter.hutterer at who-t.net> 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?