Around 21 o'clock on Sep 23, Ivan Pascal wrote:
> > 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.
Yes, it looks like you're correct -- every example I could find would
ensure that pending device input was marked in checkForInput. There are
some odd examples of this however, which are somewhat instructive to
examine:
a) The original A/UX server had checkForInput marked from the SIGIO
handler and read device events in ProcessInputEvents.
b) Many old servers never set checkForInput. The default values
point at two different values, so ProcessInput events would be
called each time around the Dispatch loop.
> 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).
Whether any events end up getting enqueued isn't relevant; the issue is
making sure the keyboard driver is given higher priority than the timers
so that any pending processing is performed before the pending timer is
executed. In essence, we're defining a static priority scheme to schedule
between the three operations:
1) Device input
2) Timers
3) Client requests
Whatever check is deemed sufficient to detect pending device input must be
performed before the timers are checked; if the only check necessary is
looking at the checkForInput values, then that's all we need to do.
> > 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?
That would only be necessary if performance across timer execution were a
critical factor -- essentially what we're forcing by returning 0 is
another call to select, which will do all of the file descriptor checking
necessary. It seems simpler to let the existing code handle this case.
However, it does somewhat beg the question of what it means for
WaitForSomething to return 0. Right now, the only case is when there is
pending input to process and no clients are ready.
> 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.
To some degree, it hardly matters -- you'll see that having
WaitForSomething return 0 causes Dispatch to simply loop back to the top
and call WaitForSomething again. I think it's a balance between concise
semantics for WaitForSomething and clearly understandable code inside each
function.
-keith
_______________________________________________
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
