[cairo] Getting cairo to clean up after itself
keithp at keithp.com
Fri Jul 15 12:30:05 PDT 2005
On Fri, 2005-07-15 at 11:47 -0700, Carl Worth wrote:
> 1) I chose "cairo_debug" as a prefix to emphasize that this function
> shouldn't be needed in "normal" operation of cairo. Also, there's
> no cairo_t* argument which might be expected if it were named
> 2) Along with the new prefix, I put the new function in a new public
> header, <cairo-debug.h>. Can anyone anticipate other functions that
> we might also put here? If not, is it overkill to add this new
> header for this single function?
No, I can imagine adding functions that enable more comprehensive (and
possibly expensive) argument checking to this interface.
> 3) As for "purge_caches", this name is a bit over-specific. Currently,
> everything that this function cleans up is named "cache" in the
> implementation. But in fact, several of these are actually hash
> tables, not caches, and the upcoming rewrite will fix that. See
> also the discussion of semantics below. Does anyone have a good
> suggestion for what to name the overall operation we're performing
> here? Suggestions based on popular library conventions will be
> particularly favored, (with a preemptive rejection on my part for
> anything modeled after glib's g_blow_chunks).
It's more like a cairo_debug_reset_static_data function where cairo sets
all data/bss back to the state they were at program invocation time.
> 4) There are a couple of interesting questions about the semantics of
> this function call. The implementation in the current patch marches
> through all static objects, (hash tables and caches), and destroys
> every entry. This is a totally bogus thing to do if the hash tables
> are still in use though. So, as is, the function could really only
> be called once the user was totally done with cairo, (eg. every
> cairo object finished or destroyed).
> But really, once all cairo objects are destroyed, then all of the
> hash tables should already be de-populated anyway. So this new
> function really shouldn't touch those. That would free up the
> semantic restriction of when this function could be called. And it
> would also make "caches" in the name perhaps not too over-specific
An assertion that checked that each hash table really was empty would be
useful here. That the function is called cairo_debug should steer normal
applications away from trying to use it while things were active.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/cairo/attachments/20050715/dc18c1d4/attachment.pgp
More information about the cairo