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.
Doing it here will waste a lot of CPU time grubbing through event queues
which should signal content with the input check.
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':
1) DoTimer called only when all pending input processed.
a) After select
b) After checkForInput tested
c) After devicesReadable is checked
2) DoTimer called even if server swamped with client input
a) Must check timers even when select returns positive
3) DoTimer effects on file descriptors respected (not that any known
instances exist)
a) Return 0 after any timers processed
4) Minimal system calls in "normal" case
a) Call GetTimeInMillis() as few times as possible
b) Don't call ProcessInputEvents from WaitForSomething
Let's gather more suggestions and then look at how the code should be
structured.
-keith
_______________________________________________
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
