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
Just copy the schemas to the builddir and compile them in place instead
of trying to mess around with creating the compiled file in a different
dir. This solves issues in the summary/description testcase when
GSettings expects the usual situation of having the .xml files present
in the same directory.
Skip the tests on inf/nan strings for the gvariant and strfuncs tests, and
skip the hex strings for the strtod tests in strfuncs as they are C99
features that are not yet supported by Visual C++ (even 2013). Use a
definition for NAN and INFINITY (that is also used in PyGObject) as
atof("NaN") and atof("Infinity") simply returns 0.0 (which is not a NAN)
in Visual C++ to fix the tests running there.
Also adapt to the format of g_ascii_formatd() when dealing with 1e99.
https://bugzilla.gnome.org/show_bug.cgi?id=711047
Use a Windows-style .bat script for the test_spawn_script() test, at least
when the code is built with Visual C++ (due to differences in how scripts
are written for shells and Windows cmd.exe), and account for Windows-style
line endings for that test too.
Let the MinGW builds (which are normally done in an MSYS BASH-style shell) continue to use the
*NIX-style script for that test.
https://bugzilla.gnome.org/show_bug.cgi?id=711047
We need to check for the correct line endings on Windows (\r\n) for the
echo tests and currently need to skip the test_echo_eof test there, as
it depends on the cat utility that is not normally found on Windows, and
using an external installation of cat via MSYS or Cygwin would render the
test program to hang as cat waits for user input.
https://bugzilla.gnome.org/show_bug.cgi?id=711047
Remove the parts about storing up the fd's in a data structure, but call
close() on the fd's. However, retain the _get_osfhandle() check on the
fd's when we iterate through the fd's as on fd values in the iteration may
well be invalid fd's. As a result, the invalid parameter handler is still
needed for newer Microsoft CRTs (8.0/2005+) for _get_osfhandle() to
make sure that the program does not abort when we check the validity of
fd's to be closed in the loop[1].
[1]: http://msdn.microsoft.com/en-us/library/ks2530z6%28v=vs.80%29.aspx
...and only include unistd.h when we are on *NIX.
Newer Visual C++ runtimes (8.0/2005 and later) will cause the program to
crash with an internal abort() call when they detect instances of close()
being called on an invalid fd, such as when the fd is -1, and these should
be purged anyways.
https://bugzilla.gnome.org/show_bug.cgi?id=711047
...Under various compilers when !G_DISABLE_CHECKS. Previously, the
messages that are logged differ depending whether GLib was built with GCC
or not. To simplify test cases, make all builds use a single output format
for g_return_if_fail(), g_return_val_if_fail(), g_return_if_reached(), and
g_return_val_if_reached(), by using the GCC-style format and replaceing
__PRETTY_FUNCTION__ with G_STRFUNC, so that it will work across various
compilers.
https://bugzilla.gnome.org/show_bug.cgi?id=711047
