On Tue, 25 Jun 2002, Gregory McGarry wrote:

> Julio Merino wrote:
>
> > > The only problem I can see is that you're reading the dynamic state
> > > from the kernel.  Once you return to userland, there is no guarantee
> > > that the returned value is correct any more.  You can tell if an
> > > event occurred, but not infer any precise kernel state.
> >
> > Well, in fact this does not matter from the point of view of the mouse
> > daemon. All I need to know is when events happen...
> >
> > Though I think that event's data is quite trustable. Can you explain
> > why it may be wrong?
>
> Your example code said this:
>
>                 if (poll(pfd, 1, INFTIM) <= 0)
>                         warn("failed");
>                 read(fd, &evt, sizeof(evt));
>                 /* XXX */
>                 if (evt.type == WSCONS_EVENT_DISPLAY_SWITCH)
>                         printf("New display: %d\n", evt.value);
>
> Which isn't necessarily true.  If the display is changed at /* XXX */
> then evt will hold stale information and the printf() statement is
> incorrect.

I've only been skimming this thread (and also haven't seen the rest of the
kernel code), but it strikes me that you're splitting a hair. *No*
userland daemon can have a 100% accurate view of the kernel state, as
messages have to cross the kernel-userland barrier. I mean the same thing
can be said of routing daemons & such.

I mean is it really stale? There was a display switch that moved the
screen to screen evt.value. The fact that there was another change just
after it doesn't invalidate that event notice. :-)

I think the important question would be though does the code keep checking
for events? If it does, then it seems like it's doing the best it can.

Or was your complaint something else?

Take care,

Bill