Re: More explanation of g_blow_caches / g_debug_shutdown
- From: Michael Meeks <michael ximian com>
- To: Tim Janik <timj gtk org>
- Cc: Owen Taylor <otaylor redhat com>, Gtk Hackers <gtk-devel-list gnome org>
- Subject: Re: More explanation of g_blow_caches / g_debug_shutdown
- Date: Mon, 12 Nov 2001 18:44:45 -0500 (EST)
Hi Tim,
On Tue, 13 Nov 2001, Tim Janik wrote:
> well, say we introduced:
> #ifdef G_ENABLE_DEBUG
> guint g_object_get_n_alive_objects (void);
> #endif
>
> would that be enough for you?
I think the method should be always available so we can link
easily, but should simply return 0 if G_ENABLE_DEBUG is not turned on;
_although_ one could consider the performance loss of maintaining a simple
count of live objects insignificant and always do it - we do this in
ORBit2 and libbonobo.
As for whether it's enough - sure; it seems fine I suppose - if
that's what you want; I'd quite like to get the dump of leaked refs at the
same time but not fussy about the method name - the status is the
important bit.
> well, this is going to be a normal public API call then, say something
> like:
>
> void gtk_blow_caches (void);
> void gdk_blow_caches (void);
> /* pango, anyone? */
> void g_blow_caches (void);
>
> and all of them chaining down.
Yes - sounds ideal.
> the name is not so important however, the implementation is what needs
> hard work ;)
And I'm happy to do it; mercifuly the current reference tracking
makes the detection of an 'un-blown' cache relatively easy ;-)
> i made some suggestions above, but i want to talk this over with owen
> once i catch him on irc. he tends to have his own mind about
> allocation issues anyways, and we might put a few more thoughts into
> this to ensure we don't screw up our API last minute ;)
I talked to Owen on IRC and he doesn't seem too keen for reasons
that are opaque to me, even after some discussion. As I say, I'm happy to
do the work and make sure it works, because I'll be using it all the time
- as I suspect will you :-)
Regards,
Michael.
--
mmeeks gnu org <><, Pseudo Engineer, itinerant idiot
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]