[Xcb] Whatever happened to the XCloseDisplay() hooks?

[Jamey Sharp]

On Wed, Oct 14, 2009 at 12:43 PM, Peter Harris <git at peter.is-a-geek.org> wrote:
> On Wed, Oct 14, 2009 at 3:17 PM, Jamey Sharp wrote:
>> I'd argue in a different direction: higher layers should manage
>> caches. The cairo XCB surface constructors could take a
>> cairo-xcb-connection object instead of the xcb_connection_t. That
>> object would be constructed from an xcb_connection_t and contain any
>> caches you want. The caller can decide when to allocate and free that
>> association.
>
> What if the app uses xcb_render_util directly? The
> cairo-xcb-connection destructor cannot safely call
> xcb_render_util_disconnect.

This is a red herring. Presumably xcb_render_util_disconnect isn't
usable for all the reasons we're discussing, so it needs to be fixed.
If the solution works for cairo, it ought to work for other libraries
as well, including renderutil and your planned atom bits.

So is there something fundamentally wrong with the idiom I suggested?

> If callbacks in libxcb proper are out of the question, ...

Well, they aren't, as I said. I'd just strongly prefer an alternative
if we can agree on a reasonable one. The general design principle is
"don't put anything in libxcb if it can be reasonably implemented in a
higher layer instead."

If the only choices are adding a magic xcb_aux_disconnect that
applications have to know to call, or adding callbacks to
xcb_disconnect directly, I think I'd rather put them in libxcb. But I
want my "tertium quid". :-)

Jamey