Although it's nice that GSubprocess object lives until its
child goes away, this can't be the case during cleanup and or
unloading of gio, since the GLib worker thread will run non-existant
code.
So in the case that GIO hits cleanup, we finalize the GSubprocess
regardless of the state of its child.
https://bugzilla.gnome.org/show_bug.cgi?id=711799
When G_CLEANUP_SCOPE is defined the G_DEFINE_TYPE and macros
properly push newly registered GTypes onto the cleanup list.
In addition push all the the basic types into the libgobject
cleanup list.
https://bugzilla.gnome.org/show_bug.cgi?id=711778
Partially from patches from Ole André Vadla Ravnås, and Dan Winship
There are a lot of intertwined pointer references between
types, their vtables, and other bits. Free the memory for them
all together.
Note that we still do all finalization (ie: callbacks) per type
and module, in the relevant cleanup lists.
https://bugzilla.gnome.org/show_bug.cgi?id=711778
This requires different phases getting involved:
* early: Signal all the unused pool threads, and change unused
limits to zero, so no new unused pool threads.
* default: Join all unused pool threads.
* late: Free up the unused thread queue
https://bugzilla.gnome.org/show_bug.cgi?id=711744
There are two ways of using the structs like GMutex, GCond, etc.
The first is to explicitly _init() and _clear() them. This is when you
use them as part of another structure. This case is not interesting for
gcleanup.
The other is to have them in static storage (zero-filled) and just use
them for the first time. This is the difficult case, because we don't
ever free the impl in that case.
In the first case, the impl is created and set in the _init() function.
We can therfore tell that we are in the second case if we get to the
get_impl() function and the impl is not there yet. In that case, add it
to the cleanup list.
There are probably people that allocate a GMutex as part of a
zero-filled structure and use it, then call g_mutex_clear() on it. This
is technically a violation of the API and these users will crash with
G_DEBUG=cleanup, but that's a good thing because it will cause them to
fix their code.
All threading primitives are cleaned up on the graveyard shift, so that
they can be used by other cleanup functions is libglib.
Because GPrivate has a callback, and we need to run that callback for
the main thread, we schedule two cleanups for it. The cleanup needs
to run in the cleanup scope where the GPrivate callback is defined,
so adapt G_PRIVATE_INIT to do this.
Tweaked by: Stef Walter <stefw@redhat.com>
https://bugzilla.gnome.org/show_bug.cgi?id=711744
Add a new type GCleanupScope that stores a list of things to "clean up"
when g_cleanup_clean() is called.
More importantly, define some macros (G_CLEANUP, etc) that
facilitate conditionally building a per-library/executable cleanup list
if G_DEBUG=cleanup is specified. The cleanup list is run at destructor
time.
-DG_CLEANUP_SCOPE defines the name of the cleanup list and enables the
feature for a given module.
Concept and initial work: Ryan Lortie <desrt@desrt.ca>
https://bugzilla.gnome.org/show_bug.cgi?id=627423
