Re: Wrong order of a timeouts processing in WaitForSomething.

[Egbert Eich]

Keith Packard writes:
 > Around 21 o'clock on Sep 21, Egbert Eich wrote:
 > 
 > > That was my suggestion. But I'm afraid xkb doesn't work like that.
 > > Not xkb checks for pending input the ddx layer does in a wakeup 
 > > handler that does so and passes information on to xkb. 
 > > The timeout handling would have to be moved from xkb to ddx.
 > 
 > The XKB code could call ProcessInputEvents just above the check for a 
 > pending repeat key; that would ensure that any input queued either in the 
 > X server or the kernel would get processed before repeat status was 
 > checked.
 > 
Hm, doesn't ProcessInputEvents() only process the events already in
the queue on the server? From looking at the code it doesn't seem
to do a read() to obtain events that have not been read from the
kernel - but that's what we'd need.

 > > I agree, but I don't think there is a restriction on the amount of 
 > > processing done before the events are queued. Therefore events could
 > > be processed far enough to know if a pending timer for a repeat should
 > > be canelled. But then this would require more extensive changes in xkb.
 > 
 > The server really can't process events even this far -- detecting which 
 > keysyms are associated with each key requires accessing keymap tables 
 > which may be manipulated by clients outside of the signal handler.  It's 
 > far easier to restrict SIGIO processing to event queuing -- that requires 
 > no global server state aside from the event queue itself.

OK, I see. A call to the signal handler while the keymaps are
being manipulated is definitely not a good idea. However we deal with
such things for mice also. There we block signals whenever we get
into the situation that an asynchronous update to the cursor position 
could disturb other things. 

 > 
 > > I think that's what Ivan's patch does: The only place where timers are
 > > called is after the select and the WakeupHandlers.
 > 
 > The timers are invoked just before the test for queued input; moving the 
 > queued input test above that should eliminate cases where key events are 
 > queued with SIGIO and then not processed before the timer function is 
 > invoked. 

This would cause the timer functions being called even less
frequently.

 >  In any case, the current spot isn't sufficient as the timers 
 > will never be executed if the server is constantly receiving application 
 > input, so at least that needs to be fixed.
 > 

One could move the timer handlers past the end of the 
if (i <= 0) { } else { } statements. However with input queued
(ie when the mouse is constantly moved) the timers don't get
called either.

Egbert.
_______________________________________________
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel