[Xcb] XCB error handling; my ultimate proposal

[Jamey Sharp]

On Fri, Dec 23, 2005 at 10:06:55PM -0800, Barton C Massey wrote:
> After some more thought, here's the only proposal I'll be
> happy with: Plan 7. :-)

Like Vincent, I was hoping we'd reach Plan 9 before stopping. :-)

Just for the record I'd like to point out that everywhere you
said "two-argument *Reply", I'm pretty sure you meant the
current three-argument *Reply functions.

>   For every request expecting a reply:
>     Provide a *RequestBlind() version of the request that
>     defers errors to the event queue.  Retain the
>     two-argument *Reply() function.  For *Request(), if the
>     second argument is not a 0 pointer, it is filled in with
>     the error record.  Otherwise, the error record is
>     discarded.  For *RequestBlind(), the second argument to
>     *Reply() must be a 0 pointer (else an assertion
>     failure), and any error records are put in the event
>     queue.

You really want current code to entirely discard errors?

Is "Blind" the best choice of name? I don't have any
alternatives...

Should it really be considered a programming error to pass a
non-null pointer to *Reply on a cookie used with *Blind? I
believe I mentioned in a previous e-mail that it would be nice
in generic code like the xcb_reply library to be able to get
the error if it was kept out of the event queue, without
caring which kind of cookie it has.

>   For every request not expecting a reply:
>     Provide a *RequestChecked() version of the request that
>     keeps errors out of the event queue.  If a
>     *RequestChecked() was issued (and returned a non-zero
>     sequence number), the application is responsible for
>     calling
>       XCBGenericError *XCBRequestCheck(XCBVoidCookie c)
>     at some point; this will sync the connection up to the
>     given sequence number and return 0 if the request
>     succeeded else a pointer to the error, which will not
>     appear in the event queue.  Failure to call
>     XCBRequestCheck() when needed is essentially a memory
>     leak.  For the unchecked *Request(), any error will
>     appear in the event queue, and a call to
>     XCBRequestCheck() will cause an assertion failure.

For consistency of semantics and names, how about using
*RequestChecked and *Request for both void and non-void
requests? The impact on existing code is a little bit higher
that way, but as you've observed this functionality isn't
widely used right now...

> I can imagine Keithp objecting that for now we shouldn't
> code such a complex scheme until we need it, and instead
> should just do the part that doesn't let errors into the
> event queue for now.  However, some of the XCB demos really
> want to just exit on any error, and for the ones that
> actually read the event queue this mechanism is perfect.
> Further, I really want to code my upcoming toolkit (yes, I'm
> gonna do it) in the style that lets most errors cause an
> exit in the event handler but catches "expected" errors
> inline.  Plan 7 lets me do this.

I'm with you on this point. (And I'm really looking forward to
your toolkit.)

> I can imagine Jamey objecting that the second argument to
> *Reply() is still an affront to god and man, and should be
> elided now while we have the chance.

Yeah... :-/ Well, I'm happy you understand, anyway. :-)

> However, it is sometimes quite convenient to both keep an
> error out of the event queue and discard it unexamined; the
> current xcb-demo code sometimes does this.  The two-argument
> *Reply() makes this quite easy, and is harmless otherwise
> IMHO.

I suppose. It's not that hard to call free immediately after
forcing the cookie, but that's OK.

> Note that, unlike my *penultimate* proposal (Plan 1) this is
> my *ultimate* proposal. :-)

Yeah, I had wondered about that. Very forward-looking of you.
:-)

> At this point, I'm out of proposaling.  I can help implement
> this if we decide to go this route, but I suspect it's
> mostly going to be Jamey's job.

No doubt. :-) Well, all of these plans have struck me as
pretty straightforward to implement.

> I'm sure Jamey and Keithp would welcome comments on Plan 7
> or any of the others by outside folks.

Absolutely.

Thanks Bart! I think we're nearly at a solution.

--Jamey
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.freedesktop.org/archives/xcb/attachments/20051228/a24f506e/attachment.pgp