> Around 21 o'clock on Sep 22, Ivan Pascal wrote:
>
> > Also I added a flag for timers TimerNeedsCheckInput. The timers without this
> > flag are processed before the select all others are delaied until the second
> > timers check. (The second check doesn't distinguish those timers.)
>
> I think that's overkill; the simple expediency of returning 0 from
> WaitForSomething after a timer has been processed will make sure that any
> effects of the timer are reflected at every scheduling stage.
>
> > WakeupHandler(i, (pointer)&LastSelectMask);
> > + ProcessInputEvents();
>
> Calling ProcessInputEvents from WaitForSomething is not appropriate;
> input events are already processed by dispatch at the appropriate time.
I agree. It was a silly kludge.
> Instead of attempting to patch the code to kludge things into working,
> let's try to nail down precisely how things should work and then rewrite
> the code to match that. Here's a short list of 'requirements':
Thank you. Offering my patch I want to hear an opinion of those who know
well how this loop works.
> 1) DoTimer called only when all pending input processed.
>
> a) After select
> b) After checkForInput tested
Agree.
> c) After devicesReadable is checked
But here I don't understand why this check is needed.
If the select returns some readable devices fd's they all should be read
in Wakeup handlers immediately after the select and this reading should be
reflected in checkForInput. Moreover it can happen that a driver reads events
from the kernel but doesn't put any events into the servers queue (for example
the keyboard driver that processes VT- or VMode-swithing internally).
> 2) DoTimer called even if server swamped with client input
>
> a) Must check timers even when select returns positive
Agree.
> 3) DoTimer effects on file descriptors respected (not that any known
> instances exist)
>
> a) Return 0 after any timers processed
Is it possible to check changes in the file descriptors set instead of just
the fact that some timer was processed?
I imagine something like:
save AllSockets
do timers
if XFD_ANYSET in (saved_AllSockets XOR AllSockets)
return 0;
Or what do you mean?
Also I think it is not necessary to return in the branch 'the select returned 0'
because in this case there are not any action with sockets and WaitForSomething
returns in loop back to the select.
> 4) Minimal system calls in "normal" case
>
> a) Call GetTimeInMillis() as few times as possible
> b) Don't call ProcessInputEvents from WaitForSomething
Agree.
The next version of the patch attached (WaitFor.c only).
I didn't make the 'return after the timers processing' but just put a comment
where I think it should be done.
--
Ivan U. Pascal | e-mail: [EMAIL PROTECTED]
Administrator of | Tomsk State University
University Network | Tomsk, Russia
_______________________________________________
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
