Now that GMutex is exposed we can avoid the dance we did in ./configure
to allocate the correct amount of space for it within the GStaticMutex.
Remove the checks and move the definitions to gthread.h, trying very
hard to keep ABI-stable (even though we will be deprecating this soon).
The original GMutex/GCond rework patch introduced some temporary code to
cope with GLib's old approach to thread initialisation. These are no
longer required.
Now that nothing inside of GLib is using g_cond_new(), we can implement
it using GSlice. Since the implementations for POSIX and Windows are
now the same, move it to gthread.c.
Now that nothing inside of GLib is using g_mutex_new, we can implement
it using GSlice. Since the implementations for POSIX and Windows are
now the same, move it to gthread.c.
Do a substantial rework of the GMutex and GCond APIs.
- remove all of the macro indirection hackery which is no longer needed
since we dropped support for switchable thread implementations
- expose the structure types and add G_MUTEX_INIT and G_COND_INIT
static initialiser macros
- add g_mutex_init() and g_mutex_clear() for use when embedding GMutex
into another structure type and do the same for GCond as well
- avoid infinite recursion hazards by ensuring that neither GCond or
GMutex ever calls back into any other part of GLib
- substantially rework the Windows implementation of GCond and GMutex
to use the SRWLock and CONDITION_VARIABLE APIs present on Windows
2008/Vista and later, emulating these APIs on XP
Otherwise we might collide with an interface called Connection.
https://bugzilla.gnome.org/show_bug.cgi?id=659699
This is for the same reason that GDBusProxy has its properties
prefixed with g-.
Signed-off-by: David Zeuthen <davidz@redhat.com>
We ignore entries with mountpoint of "swap" and "ignore". Add "none" to
that list, since Debian uses it.
Probably we should move to using our already-existing internal list of
things to ignore, but this patch is more minimally intrusive for now.
https://bugzilla.gnome.org/show_bug.cgi?id=654563
Commit afa82ae805 introduced a compilation
regression on BSD systems that use the sysctl(3) interface; we need to
declare the buffer len in _g_get_unix_mount_points()
BZ #659528
In registration_data_export_interface(), the object_path is obtained using:
object_path = g_dbus_object_get_object_path (G_DBUS_OBJECT (data->object));
But when exporting an object uniquely, the object_path is not assigned
to the GDBusObject until after all the interfaces are exported.
Therefore, registration_data_export_interface() is trying to export
the interface on the non-unique object path, which can lead to
run-time errors if an object already exists on that path.
Instead, registration_data_export_interface() should be passed the
object_path explicitly, as is done in
g_dbus_object_manager_server_export_unlocked().
Signed-off-by: David Zeuthen <davidz@redhat.com>
Ensure that the output/target stream in a g_output_stream_splice_async()
operation is marked as closed if G_OUTPUT_STREAM_SPLICE_CLOSE_TARGET is
passed to g_output_stream_splice_async(). This removes the possibility of
local FDs being closed twice because the stream's not marked as closed.
This is implemented by calling g_output_stream_close() from within
g_output_stream_splice_async() instead of calling the stream's close_fn()
directly.
Closes: bgo#659324
Create a deprecated/ directory that we can start moving ancient chunks
of code to. Start with GAllocator, GMemChunk and related APIs.
Also drop all mention of them from the docs.
https://bugzilla.gnome.org/show_bug.cgi?id=659427
Implement g_ascii_strto{d,ll,ull} and g_ascii_formatd using
xlocale functions where available. This is slightly faster
and a lot less icky than our homegrown code.
https://bugzilla.gnome.org/show_bug.cgi?id=640293
Previously, we were returning an empty buffer for all filenames
where fstat() gives a size of 0. But this is only appropriate
for regular files.
Also improve the documentation around this issue. Based on a
patch by Ryan Lortie.
Conflicts:
glib/tests/mappedfile.c
https://bugzilla.gnome.org/show_bug.cgi?id=659212
