Re: X11 timestamp problems? (Re: Minutes of the GNOME Board meeting 19 March 2001)



Keith Packard and I discussed this with Owen last summer.  And it isn't 
just GTK or other recent toolkits: many/most of the new window managers 
suffer from this problem (e.g. enlightenment). When we talked to Owen, 
he said it would take some additional GTK API's to fix the problem (and 
update applications to use them in some cases).

Many/most people building toolkits and window managers in the last 5-7 years
have not understood the reason for passive grabs and timestamps in the
X protocol that are explictly there to solve race conditions.  Unfortunately,
all of the previous X implementers had gone off to other things, so the
cultural heritage was lost.  Sigh...  Work needs to be done in both
to get this right.

Let me give an example:

Say you have an application paged out (or are starting up an embedded 
application), and you suddenly raise a the application's window to the 
top of the stack and click on a button.  You want the event to be delivered 
to the right window.  A user can easily get ahead of the system (less 
so now that so many machines have so much memory, but it still happens).

Right now, what often happens is the event gets delivered to the wrong
application.  It is seriously annoying: something I expect out of Windows,
and didn't used to happen on X desktops.

OK, how do you solve this problem?

In the X protocol, it is possible to do what is called a "Passive grab",
which can be thought of as setting a trap.

When the trap (grab) springs, you can arrange to freeze event processing.

Then toolkits and window managers can madly get in there and get the
window heirarchy all set up, and once done, you can "Allow Events", 
(or "replay events", in the case of wanting to set input focus to a window
while simultaneously getting the event sent to an underlying window to
set the input point, for example).

Then you release the trap (the grab) and allow the queued events to
be delivered (now to a different window than they would have without
the grab).

So then the event gets sent to the "right place".

All this uses the timestamps in events to make come out right.

So work needs to happen in both window managers and toolkits.

There are a few mistakes we made in the protocol design: all events
should have had timestamps, and a few don't: we didn't forsee how they
might be used, so we didn't include them.  This was a mistake as there
turn out to be situations where they would have been useful.  But we got
most of this right, just not perfect (so there are a few uncommon races
you can't avoid, at least not without us adding to the core X protocol,
which again is more feasible than in the days of the X consortium.

You should read "Why X is Not Our Favorite Window System", by
Mark Manasse and Hania Gajewska (sp).

Most of the core X papers including this one are in a special issue of 
"Software Practice and Experience" on the X Window System, June 1991, 
which should be in any major library.

Hope this helps.

                              - Jim

--
Jim Gettys
Technology and Corporate Development
Compaq Computer Corporation
jg pa dec com





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]