[cairo] Getting cairo to clean up after itself

[Keith Packard]

On Fri, 2005-07-15 at 11:47 -0700, Carl Worth wrote:

> Naming
> ------
> 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
>    cairo_purge_caches.

Sensible

> 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.

> 
> Semantics
> ---------
> 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
>    anymore.

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.

-keith

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/cairo/attachments/20050715/dc18c1d4/attachment.pgp