Re: More explanation of g_blow_caches / g_debug_shutdown

[Owen Taylor <otaylor redhat com>]

[ This has been sitting in my outbox since last week; I meant
  to send it off before not listing debug_shutdown() in the list
  of outstanding API stuff ]


I'd really like to hold off on doing this.

Explaination:

 * I think that debug_shutdown() functions do violence to the
   code base. It means that widgets (etc,) that should be completely
   independent of core code suddenly need hooks into the core.

   It's great that Michael has volunteered to do the maintainence
   of the ugly code, but sometimes even when you have a volunteer,
   it's still not a good idea to introduce ugliness into the
   code.

   In fact, if we were going to do debug_shutdown() I'd probably
   want to see some sort of registration functions rather than
   a lot of _gtk_colorsel_debug_shutdown() style functions. 
   _gtk_colorsel_debug_shutdown() functions also cause problems
   for static linking by introducing inter-object dependencies
   that aren'tneeded.

   But I really don't think we should add some sort of debug-shutdown
   registration hook API at this time.

 * debug_shutdown() is far from a perfect memory leak detection tool;
   it basically has the same problem as doing leak detection with 
   conservative GC; if you are keeping a block around in a cache somewhere, 
   you will not treat it as a leak, even if you have allocation growing 
   without bound.

   For memory leak detection, if you can:

    - Do conservative GC to detect unreferenced pointers. (Boehm GC, 
      Debauch, Memprof)

    - Diff memory usage profiles between two points in a program.
   
   Then, in my opinion, you will be in a good position to find 
   almost any memory leak.

   I know that quite a few people disagree here and I probably can't
   convince them. So perhaps we do need to something in this regard
   for GLib/GTK+-2.2; but to the extent _I_ do anything, I'd much
   rather spend a bit of time make memprof a really useful tool (by
   adding memory usage profile diffing, for example) rather than
   spend time registering memory/objects for freeing.

 * Finally, doing this work for GDK and GTK+ currently is wasted effort
   since much of this will fall out naturally when we do memory management 
   for multi-head support correctly. If you close a display, then caches for
   the display must be freed at that point; while this isn't going to be
   _all_ cached memory, it will be a great deal of it, and should be
   virtually all objects.

 * We just can't add API stuff at this point.

Regards,
                                        Owen