On Mon, Jun 24, 2002 at 04:11:43PM -0700, Bill Studenmund wrote:
> 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?

Depends on the /* XXX */. If this is a "draw some characters to screen" an
overseen screen switch would yield "interesting" results.

What about locking instead of event monitoring? Something like:

		ioctl(fd, WSDISPLAY_LOCK, &on);

		/* XXX */

		ioctl(fd, WSDISPLAY_LOCK, &off);

-- 
Juergen Hannken-Illjes - hannken@eis.cs.tu-bs.de - TU Braunschweig (Germany)