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

Josh Triplett josh at joshtriplett.org
Wed Oct 14 13:39:57 PDT 2009

On Wed, Oct 14, 2009 at 03:43:30PM -0400, Peter Harris 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 nightmare arises if you take that approach?
> What if the app uses xcb_render_util directly? The
> cairo-xcb-connection destructor cannot safely call
> xcb_render_util_disconnect.
> I've been toying with the idea of extending xcb/util/atom to contain a
> prefetch interface (not dissimilar to xcb_prefetch_extension_data).
> Assuming this sort of general interface is eventually used by cairo,
> the cairo-xcb-connection object cannot shut it down just in case it is
> also used directly by the app (and/or other libraries).
> So you wind up having to shut down every little helper library in
> every single app, even the ones you don't realize you are using
> indirectly. That doesn't sound like much fun to me.

This, to me, seems like an argument for each library holding its own
references, rather than counting on those provided by other pieces of
the program.  Anything the library decides to share internally should
stick around until all references go away.


- Josh Triplett

More information about the Xcb mailing list