[Xcb] error handling for void requests

[Jamey Sharp]

[I'm moving this part of this thread from the Cairo mailing list,
because I want the XCB community to comment on these proposed changes,
and because details of XCB's API aren't all that relevant on the Cairo
list. The original thread begins at
http://lists.freedesktop.org/archives/cairo/2005-May/003957.html .]

On Sun, 2005-05-15 at 21:01 -0400, Owen Taylor wrote:
> On Sun, 2005-05-15 at 12:14 -0700, Jamey Sharp wrote:
> > On Sun, 2005-05-15 at 11:13 -0400, Owen Taylor wrote:
> > > On Sat, 2005-05-14 at 19:37 -0700, Jamey Sharp wrote:
> > > > Memory allocation failure is one possibility. More likely is an X error
> > > > being returned instead of the desired reply. Also, if the X server
> > > > connection closes, you should get a failure return from functions trying
> > > > to access server data that hadn't arrived before the loss of the
> > > > connection.
> > > > 
> > > > If you can usefully handle X errors from this request, then you should
> > > > pass a reference to a XCBGenericError* as the third argument to the
> > > > XCB...Reply function, and it will be filled in if an error occurs. By
> > > > passing a null pointer as above, any error will be inserted into the
> > > > event queue instead for the application to handle.
> > > 
> > > Thinking about some hypothetical future where Cairo is using XCB
> > > internally in an application that is using Xlib, it seems like Cairo can
> > > never rely on the "error event" approach, because the app at best will
> > > just ignore the unknown event.
> > 
> > I assume you mean that this hypothetical application is using a version
> > of Xlib that has XCB support compiled in. One piece of that XCB support
> > involves pulling all events and errors out of XCB's event queue, and
> > handling them in a manner compatible with Xlib (unless the application
> > requests that all events and errors be left in XCB's queue). In
> > particular, errors are passed to the usual Xlib error handler.
> >
> > XCB keeps errors and events in the same queue simply because that way
> > their relative order is maintained. That would be a weird notion in Xlib
> > due to Xlib's callback-oriented error-handling, but XCB doesn't do
> > callbacks.
> 
> Two problems with this occur to me:
> 
>  - if I make a request (without a reply, say), it seems that an Error
>    reply could be processed out of the event queue by another thread
>    before I had a chance to do anything about it. 
>  
>  - If I'm mixing libraries together, I have no real way of getting
>    a callback for a delivered event ... so I can't find out when
>    an Error occurs for a request I make.

Certainly true on both counts.

> Another way of doing things, which fits in closer to the XCB current
> model would be to have some way of executing requests and directing
> errors to a "secondary event queue". 
> 
> (A bit like a Java ReferenceQueue:
> http://java.sun.com/j2se/1.4.2/docs/api/java/lang/ref/ReferenceQueue.html,
> used by WeakReference and friends:
> http://java.sun.com/j2se/1.4.2/docs/api/java/lang/ref/WeakReference.html)
> 
> This just allows batching, not asynchronicity for a single-threaded
> app but is general for a multi-threaded app.

I really like that idea, because it solves the above problems and others
as well. One implementation difficulty in the current architecture is
that XCB doesn't know whether it needs to enqueue an error in the event
queue until the application tries to wait for a reply for that error's
sequence number. A client-managed event queue, registered when the
request is made and regardless of whether the request should return a
reply, would solve that problem beautifully.

> If I make a request, I "own" that request, and I should have some
> mechanism for getting a first crack at the reply. Callbacks are an
> obvious way of doing that, and really the only sensible  way to do thing
> in a single-threaded app. 

The process of discarding errors in response to void requests can be
deferred until the next synchronous request has been responded to, as
long as those errors were expected and should be ignored; but special
support for this case could be provided, I suppose. If code sending a
void request needs to know whether it failed, then it should Sync or
something and then poll its error queue. Unexpected errors should
probably be left in the event queue still, so that the application can
choose how to handle programming errors like that. In any case I don't
see that callbacks make all that much difference to practical usage.

Given polling functionality on the client-managed queue, I think
callback code is implementable in a higher layer, which I'm not opposed
to doing. It's just that callbacks make it so hard to reason about
invariants, and XCB already needed the application of some formal
methods to avoid deadlocking the X server, so I don't want more
impediments to reasoning about correctness.

--Jamey