the pros of gtk_debug_shutdown

[Michael Meeks <michael ximian com>]

Here are some of the pros and cons of having a _debug_shutdown method:

	Just to say to start with that I propose a purely optional
shutdown method. It needs to be a method, since it is nice to return
non 0 from a regression test when something fails - eg. a leak.

Pro:
	* trivialy allows a library to be tested for leaks
	* adds no overhead for the common case
	* not an atexit method
	* allows fully automated - leak checking on distchecl
	* allows very frequent leak checking by developers
	* stackable - thus gtk+ would shutdown itself, then pango,
	  then glib, involving a single method call at 'main' exit:
		return gtk_debug_shutdown ();
	* unambiguous the '_debug_shutdown' makes the method's
	  purpose quite clear.
	* could be used inside Gtk+ to verify ref counting correctness.

Con:
	* adds a new public method, and possibly some internal ones.
	* all static / cached GObject resources have to be freed
	  by explicit code - not too tough, since we know where they
	  all are.
	* shutting down modules might be more complex (unlikely)
	* requires some maintenance - when you add new global members.

	So ...

	Can someone possibly explain to me why this would be a bad
thing ? yes it will involve some work - I am very happy to do that
work and maintain it; I ask only the entry points to make it possible
for now.

	Please - as pro 1 says, it would _really_ help me find leaks,
and be so much more confidant about library code that is shipped -
that it is verified as good as it can be - automaticaly.

	Thanks for listening,

		Michael.

-- 
 mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot