[Mesa-dev] [PATCH] egl: Add GetSyncValuesCHROMIUM extension.

[Ian Romanick]

On 04/18/2014 05:07 PM, Jamey Sharp wrote:
> On Fri, Apr 18, 2014 at 4:49 PM, Ian Romanick <idr at freedesktop.org> wrote:
>> On 04/18/2014 03:37 PM, Sarah Sharp wrote:
>>> One open question:
>>>
>>> I've used the normal (error checked) version of xcb_dri2_get_msc.  The
>>> GLX implementation of glXGetSyncValuesOML uses the unchecked version,
>>> but I'm not convinced it's necessary.
>>>
>>> I talked to Jamey Sharp, and he doesn't understand why most of Mesa
>>> calls the unchecked versions of XCB functions.  He thought most
>>> developers would want to use the normal (checked) versions, since the
>>> unchecked versions may segfault on errors.  Mesa can always call the
>>> checked version, but ignore the error that's set, so it doesn't have to
>>> use the unchecked version.
>>
>> When I added some XCB code to Mesa a couple years ago, it wasn't
>> completely clear to me what the difference was between the checked and
>> unchecked versions.  See 6ccda72 and 588042a.  My recollection was that
>> the _checked versions returned a cookie that you had to do something
>> with.  For a bunch of the cases, I think we don't want to do the extra
>> bookkeeping (or we don't want the extra opportunity for a memory) leak.
>>
>> Is there more difference than I know?
> 
> The key difference, in the case of requests that expect a reply, is
> what happens to an X error if the server sends you one of those
> instead of the reply you were expecting. In the checked case, XCB
> returns that error to you when you ask for the reply, through an
> optional out-parameter in the reply function. If you use the unchecked
> variant of the request, then the error is placed in the event queue;
> if you're using Xlib, then by default it will be abort()ing your
> client as soon as it pulls the error out of the event queue.

Unless the client has an error handler, right?

> There's no opportunity for a memory leak from using the default (that
> is, checked) version of requests that expect a reply. If you don't
> want to look at the details of the X error, just pass NULL for the
> third argument of the reply function, in which case XCB will free the
> error struct for you.
> 
> For requests where you do not expect to get a reply, XCB defaults to
> unchecked behavior, and you have to use the _checked variant and an
> xcb_request_check call if you want to keep the error out of the event
> queue. Since xcb_request_check may have to do a round-trip to confirm
> that no error occurred, you probably don't usually want checked
> behavior for these requests. But that's why the default depends on
> whether the request was going to have a reply anyway.

Yeah... that's starting to ring some bells.  Did I mention that I wrote
that XCB code in 2011? :)

> So I *think* you'll find life is much better in error cases if you
> just s/_unchecked//g throughout Mesa. You'll get better error
> reporting where it's free, without adding extra round-trips or
> opportunities for memory leaks where it's more complicated. But there
> could be something about Mesa's use case I still don't understand.
> 
> Jamey