[Xcb] Ideal event handling

[Jamey Sharp]

On Tue, 2005-08-09 at 01:25 -0700, Barton C Massey wrote:
> Another way to look at what Travis/GDK timestamps and the X
> error association cases want is this: A bunch of things in X
> that probably should be replies to requests are instead
> asynchronous events or errors.  I think this is because of
> X's hard constraint that replies must be delivered in
> request order.

That sounds plausible, but I can't yet convince myself of it for any of
the examples I've looked at recently. I'll think about it more.

In the case of obtaining the server timestamp, the idiom being used here
is just a hack. Many events, PropertyNotify included, carry a timestamp.
If you can get at any of those events, and know that the one you have
was generated "recently", then you have the "current" server timestamp.
Normally one would only care about PropertyNotify if some *other* client
caused it, in which case it really is an asynchronous event.

The protocol fix for this, if anybody cared, would not be to relax the
hard ordering constraint: it would be to add a "GetServerTime" request.

The client architectural fix for this would be to globally record the
last timestamp seen in any timestamp-bearing event and just use that,
only forcing such an event if the stored timestamp is somehow not recent
enough.

> It might be reasonable to allow some special kind of XCB
> requests for specific cases, whose response cookie is in
> fact a cookie that will match a particular X event.  It
> might also be reasonable to have any forced cookie
> potentially return an X error at that point (but don't we
> already do this?).
> 
> I think most of the machinery to make this work is already
> in XCB (although it would need some analysis).  This
> mechanism *might* provide a clean separation between events
> that are generated in response to requests
> (e.g. ClearRectangle) and events that are external and thus
> truly asynchronous.

That kind of machinery is there, yes, but over the last couple of days
I've come to the conclusion that it's fundamentally broken due to a race
condition. I'll post separately about that.

I'd like to see a more detailed API proposal, but off-hand I can't see
any simple API to do what you suggest, satisfy the general
event-matching needs of applications, and remain thread-safe.

All these problems can be solved if this mechanism is integrated into
the application's event/error loop instead, though. So putting this API
in the XCBEvent or XCBReply libraries might work.

> None of this handles the pointer event collapse case, of
> course.  I think Jamey has the right idea about this one.

Yay! :-)

--Jamey
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/xcb/attachments/20050810/d702e6cd/attachment.pgp