Any flags specified as well as "all" are subtracted from the result,
allowing the user to specify FOO_DEBUG="all,bar,baz" to mean "give me
debugging information for everything except bar and baz".
https://bugzilla.gnome.org/show_bug.cgi?id=642452
pthreads doesn't implement the _lock_full() and _unlock_full() calls on
recursive mutexes so we don't have it on GRecMutex either. Now that
we're using GRecMutex to implement GStaticRecMutex, we have to fake it
by keeping an internal counter of the number of locks and calling
g_rec_mutex_unlock() the appropriate number of times.
The code to do this looked like:
depth = mutex->depth;
while (mutex->depth--)
g_rec_mutex_unlock (rm);
return depth;
which unfortunately did one last decrement after mutex->depth was
already zero (leaving it equal to -1).
When locked the next time, the count would then increase from -1 to 0
and then the next _unlock_full() call would not do any calls to
g_rec_mutex_unlock(), leading to a deadlock.
https://bugzilla.gnome.org/show_bug.cgi?id=661914
We clean up the detection of if we should do 'real' atomic operations or
mutex-emulated ones with the introduction of a new (public) macro:
G_ATOMIC_LOCK_FREE. If defined, our atomic operations are guaranteed to
be done in hardware.
We need to use __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 to determine if our
compiler supports GCC-style atomic operations from the gatomic.h header
because we might be building a program against GLib using a different
set of compiler options (or a different compiler) than was used to build
GLib itself.
Unfortunately, this macro is not available on clang, so it has currently
regressed to using the mutex emulation. A bug about that has been
opened here:
http://llvm.org/bugs/show_bug.cgi?id=11174
This was turning all the GLIB_VARs in the glib headers into
dllexports on windows, causing all sort of nastiness. libgthread is
mostly empty now anyway, so we don't need any GLIB_COMPILATION like
flag.
-Move _glib_get_locale_dir to ggettext.c, as Matthias suggested
-Made up for the headers that needed to be included in ggettext.c to avoid
C4013 (implicit declaration of ...) errors/warnings
-gcharset.c, genviron.c, gunicollate.c: Some headers were missed in those
files that triggered C4013 warnings/errors (aka. implicit declaration
of ... in GCC). Make up for them here.
-gwin32.h: Only define g_win32_get_package_installation_directory/
g_win32_get_package_installation_subdirectory as macros
(alias of g_win32_get_package_installation_directory_utf8/
g_win32_get_package_installation_subdirectory_utf8) on Win64 (x64) as
g_win32_get_package_installation_directory/
g_win32_get_package_installation_subdirectory have seperate existing
implmentations for Win32-this is a long-standing problem but was covered-
up by G_DISABLE_DEPRECATED, which we are stopping to use as of 2.31.0.
Split win32 functions off into their own section, instead
of having large and unwieldy ifdef sections inside each function.
Also move the compat versions of env functions over from gutils.c
This was used as an optimisation for the macro hackery that used to live
in gthread.h. If a particular library or program knew that it could
rely on thread support being enabled, it would allow for static
evaluation of conditionals in some of those macros.
Since the macros are dead and thread support is now always-on, we can
get rid of this bit of legacy.
g_thread_init() is now a deprecated API, so drop G_DISABLE_DEPRECATED
from the CFLAGS for gthread/. Add the missing declaration for
g_thread_init_with_errorcheck_mutexes() back to deprecated/gthread.h.
This function was never put in a header and was only used internally
from libgthread, but we should keep the symbol around to avoid
triggering any false-positives on ABI checkers.
For -Wmissing-prototypes compatibility with this unusual case, we should
add a private prototype in the .c file just before.
This has uncovered two unused testcases in option-context.c. They are
currently broken and require more investigation (which is probably why
they are unused).
Document the previously uncovered case of calling g_spawn_async_with_pipes()
without a full path but no G_SPAWN_SEARCH_PATH. This runs programs from the
current directory, which might be unexpected and even dangerous in some corner
cases.
https://bugzilla.gnome.org/show_bug.cgi?id=656621
Adds g_key_file_ref and g_key_file_unref, to be used by a future
GKeyFile boxed type for language bindings.
Based on the patch by Christian Persch and Emmanuele Bassi.
Author: Christian Persch
Signed-off-by: Johan Dahlin
Signed-off-by: Giovanni Campagna
https://bugzilla.gnome.org/show_bug.cgi?id=590808
gutils.[hc] is a bit of a grab bag, so lets start cleaning
things up by moving all the environment-related functions
into separate genviron.[hc] files.
The private _g_getenv_nomalloc has been moved to its sole caller.
When spawning a child process, it is not safe to call setenv() before
the fork() (because setenv() isn't thread-safe), but it's also not
safe to call it after the fork() (because it's not async-signal-safe).
So the only safe way to alter the environment for a child process from
a threaded program is to pass a fully-formed envp array to
exec*/g_spawn*/etc.
So, add g_environ_getenv(), g_environ_setenv(), and
g_environ_unsetenv(), which act like their namesakes, but work on
arbitrary arrays rather than working directly on the environment.
http://bugzilla.gnome.org/show_bug.cgi?id=659326
01ed78d525 introduced assertion checks for
creating a main context, forking, and attempting to use the main context
from the child side of the fork.
Some code (such as gnome-keyring-daemon) daemonise after calling
GMainContext. That's probably still mostly safe since we still only
have one side of the fork touching the context afterwards.
This use case is still troubling, however, since if any worker threads
have been created at the time of the fork(), we could end up in the
classic situation of leaving some mutexes in a locked state when the
other threads disappear from the copy of the image that the child gets.
This will require some deeper thinking...
Some code using GLib (gnome-keyring-daemon, for example) assumes that
they can catch signals by masking them out in the main thread and
calling sigwait() from a worker.
The problem is that our new worker thread catches the signals before
sigwait() has a chance and the default action occurs (typically
resulting in program termination).
If we mask all the signals in our worker, then this can't happen.
Switch GCond to using monotonic time for timed waits by introducing a
new API based on monotonic time in a gint64: g_cond_wait_until().
Deprecate the old API based on wallclock time in a GTimeVal.
Fix up the gtk-doc for GCond while we're at it: update the examples to
use static-allocated GCond and GMutex and clarify some things a bit.
Also explain the rationale behind using an absolute time instead of a
relative time.
Hide the definition of struct _GThread in gthreadprivate.h for now.
This is possibly an API break -- although the structure contents were
undocumented and it was not safe to access them in a meaningful way,
someone may have tried to do it anyway. We'll leave it here for a while
to see if it causes any problems.
Avoid merging its contents with GRealThread for now, just incase we need
to expose it again.
We'll hold out on this until someone has a really convincing reason for
why they need to control the stack size.
If we do decide to add it back, it should probably have a name like
_new_with_stack_size(), not _full().
And remove the 'joinable' argument from g_thread_new() and
g_thread_new_full().
Change the wording in the docs. Clarify expectations for
(deprecated) g_thread_create().
GThread is freed using some very slightly confusing logic: if the thread
was created 'joinable', then the structure is freed after the join()
call succeeds (since we know the thread has exited). If the thread was
not created 'joinable' then the free is when the thread quits (since we
know 'join' will not be called later).
Move to a straight ref-counting system: 1 ref owned by the thread and 1
extra ref if the thread is joinable. Both thread quit and joining will
decrease the refcount by 1.
Make the POSIX backend a little bit more like the win32 one in terms of
how we deal with joinability.
Calling g_system_thread_join() is now optional, and
g_system_thread_wait() can be safely called by multiple threads.
There is no longer any internal concept of joinability.
Merge the GThreadData with the GThreadWin32 struct. Drop the extra TLS
variable.
Close the handle on _free(), which means that there is no leak if
g_system_thread_join() isn't called.
Remove all internal concept of joinability.
Keep track of if we created a thread for ourselves or if the GThread*
was allocated in response to g_thread_self() on a previously-unknown
thread.
Only call g_system_thread_free() in the first case.
Wrap GRealThread in a GThreadPosix that includes its own pthread_t field
called "system_thread" and use that instead of the generic field in
GRealThread.
Add g_system_thread_new() and g_system_thread_free(), implemented with
GSlice. Use those instead of g_new() and g_free().
Presently, the backends are both doing the same thing. This will change
soon.
The use of system_thread is now limited to joining. We don't do that
for threads that we didn't create for ourselves, so we don't need to
call g_system_thread_self() to fill in system_thread for those.
...instead of having a 'next' pointer in the GThread struct.
Now GThread contains no fields used only by deprecated code (except for
the rather generic setup function field).
Thanks to the modifications in 3d4846d923,
GStaticPrivate is not so directly tied in with GThread anymore. It is
now a simple matter to cut it out completely by using a GPrivate to
store the GArray instead of storing it in the GThread.
Unlike G_GNUC_... macros, the new G_DEPRECATED[_FOR] are
meant as abstractions that work with different compilers.
Using a new name also lets us restrict it to 'must be placed
before the declaration', which works with more compilers.
https://bugzilla.gnome.org/show_bug.cgi?id=661438
The definitions of _GMutex* and G_STATIC_MUTEX_INIT is now found in
glib/deprecated/gthread.h, and should no longer be in the mainline
code, so remove them from here.
Everything was OK as long as GMutex was backed by pthread_mutex_t on
POSIX. Since this is no longer the case, the ABI of GStaticMutex was
broken.
Fix that up by using pthread_mutex_t directly in the structure. Since
that's potentially incompatible with our GMutex implementation, set
g_thread_use_default_impl to FALSE to cause the fallback code (which
manually allocates a GMutex) to run, even in the case of
already-existing code (without the need for a recompile). This will
cause the pthread_mutex_t part of the struct to be completely ignored.
Add g_main_context_ref_thread_default(), which always returns a
reffed GMainContext, rather than sometimes returning a (non-reffed)
GMainContext, and sometimes returning NULL. This simplifies the
bookkeeping in any code that needs to keep a reference to the
thread-default context for a while.
https://bugzilla.gnome.org/show_bug.cgi?id=660994
I've seen builds fail with
nm-connection.c:119:691: error: declaration of '_GStaticAssertCompileTimeAssertion_119' shadows a previous local [-Werror=shadow]
because several compile-time assertions ended up on the same
line. __COUNTER__ is meant specifically for the purpose of
constructing identifiers, so use it when available.
0e3f530185 introduced a compiler warning
about implicit declaration of g_get_prgname(). Fix that.
Problem caught and fix suggested by Rico Tzschichholz.
We can just assume that strerror/strsignal are available
nowadays. At the same time, drop use of thread-private storage.
Instead, always return interned strings.
https://bugzilla.gnome.org/show_bug.cgi?id=660849
GTimer no longer uses the thread system for time information and
g_thread_init() no longer does anything, so remove the doubly-untrue
warning about these topics.
https://bugzilla.gnome.org/show_bug.cgi?id=527214
We can't initialise gslice from a ctor because g_slice_set_config() must
be called before gslice initialisation.
Instead, do the initialisation in a threadsafe way from the
initialisation function for the thread private data. This will only be
called once per thread so the synchronisation doesn't pose a significant
overhead here.
Ensure that we try to grab the thread private data directly on entrance
to g_slice_alloc() so that we force the initialisation to occur.
Grabbing the private data is the common case anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=660887
Instead of running the GPrivate destructors from our thread proxy code,
run it from the DllMain handler for the DLL_THREAD_DETACH case.
This should ensure that thread-local data is free at the exit of all
threads -- not just the ones we created for ourselves.
https://bugzilla.gnome.org/show_bug.cgi?id=660745
Make sure that it calls absolutely nothing that may ever recurse back
into GLib again:
- g_ascii_strcasecmp() is unsafe because it has g_return_if_fail() at
the top. As far as I know, the only ASCII character letter that
would get special treatment here is "i" and that appears in neither
"help" nor "all".
- g_getenv() is very complicated on Windows, so use a simple version
that is sufficient for our purposes.
Now that it's completely safe, we can just call it from g_logv() in the
usual way without all of the hacks.
https://bugzilla.gnome.org/show_bug.cgi?id=660744
Give the macro wrapper treatment to g_once_init_enter() and leave() in
the same style that we did for gatomic.
It is now possible to use these macros with any pointer-sized object,
and not just gsize. The leave() macro ensures that the initialisation
result is a compatible type with the pointer that it is being written
to.
Just like with gatomic, there could be problems caused by use of (void*)
casts. We'll see how that goes, and reevaluate if necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=660743
Presumably, the rationale for not storing the endianness is that
GVariant is a recursive type system, and in a sane format, endianness
only needs to be stored once per blob of data (once per D-Bus message,
once per file on disk, etc.).
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=632049
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Ryan Lortie <desrt@desrt.ca>
Also include a shorter version in the docs for g_variant_store, with a
pointer to g_variant_get_data.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=632049
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Ryan Lortie <desrt@desrt.ca>
Strings matching /%[a-z]/ are special syntax for gtk-doc.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=632049
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Ryan Lortie <desrt@desrt.ca>
This covers the str, double, int, int64 hash and equal functions, but not
anything that takes an "object", since the convention is that "object
methods" never accept NULL anyway.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=592715
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Colin Walters <walters@verbum.org>
Also annotate them as (allow-none), more for the benefit of gtk-doc
readers than introspection.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=592715
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Colin Walters <walters@verbum.org>
Using g_int_hash, g_int_equal with keys like GINT_TO_POINTER (n) seems to
be a reasonably common GLib-novice mistake. It doesn't help that the
documentation for GHashFunc was ambiguous about this.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=592715
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Colin Walters <walters@verbum.org>
The copying of code from g_async_queue_new() to g_async_queue_new_full()
in ef08aa786b copied the setting of the
free function to NULL (instead of the one passed in by the user).
Fix that up so that the test passes again.
https://bugzilla.gnome.org/show_bug.cgi?id=660843
The markup here was not only broken, it was also unnecessary,
since gtk-doc knows to apply <function></function> tags to things
that end with () already.
Add a little bit more room in the ABI for our synchronisation primatives
since we're going to need it when we add native implementations on
Linux.
Also: rename the pointer field and add /*< private >*/ annotations.
All locks are now zero-initialised, so we can drop the G_*_INIT macros
for them.
Adjust various users around GLib accordingly and change the docs.
https://bugzilla.gnome.org/show_bug.cgi?id=659866
Modify the POSIX implementation of the synchronisation primatives to use
the same ABI as Windows: one pointer for each type.
This frees us from having to #include <pthread.h> and avoids the problem
with pthread_rwlock_t not being defined under certain compiler defines.
A few more changes are expected to the ABI -- they will be committed
separately.
https://bugzilla.gnome.org/show_bug.cgi?id=659866
This commit moves GStaticPrivate, g_thread_foreach and all
related functions and variables to gthread-deprecated.c. We
introduce some internal API to make this possible.
g_thread_foreach is not a very useful function, since there is
virtually nothing you can do with a GThread*, and implementing
it requires us to keep a list of threads around.
GStaticPrivate has been made redundant by adding comparable
capabilities to GPrivate.
https://bugzilla.gnome.org/show_bug.cgi?id=660635
Deprecate both g_thread_create functions and add
g_thread_new() and g_thread_new_full(). The new functions
expect a name for the thread.
Change GThreadPool, GMainContext and GDBus to create named threads.
https://bugzilla.gnome.org/show_bug.cgi?id=660635
Take out the half-private g_private_init() stuff and replace it with a
G_PRIVATE_INIT macro that allows specifying a GDestroyNotify.
Expose the GPrivate structure in a public header.
Add a g_private_replace() to (sort of) match the functionality of
g_static_mutex_set().
Improve the documentation.
Deprecate g_private_new().
To avoid iterating threads in g_static_private_free(), defer freeing
the per-thread data to thread exit. The one complication here is
that it is possible for the static private index to be reused while
'old' data is still around. To deal with that case, store the 'owner'
with each per-thread data node, and free old data in
g_static_private_get() if the owner doesn't match. The remaining
possibility that a private index could be reused by a GStaticPrivate
with the same address is sufficiently unlikely that we can probably
ignore it.
With this change, per-thread data is now truly private again,
and we can drop the lock for it as well.
https://bugzilla.gnome.org/show_bug.cgi?id=660635
We lack SRWLock on Windows XP, so we use CRITICAL_SECTION to emulate it
there. SRWLock is non-recursive, but CRITICAL_SECTION will happily
allow itself to be acquired multiple times by the same thread.
We need to detect if our second acquire succeeded because of the
recursive nature of CRITICAL_SECTION. In the case of a _lock()
operation, we would normally have deadlocked, so abort. In the case of
a _trylock() operation, we need to ensure that FALSE is properly
returned.
Problem caught by Matthias Clasen and Chun-wei Fan.
https://bugzilla.gnome.org/show_bug.cgi?id=660096
-Include gthread.h in gregex.c as g_once_init_enter and g_once_init_leave
are used.
-Define prototype for g_thread_DllMain in gthreadprivate.h for Windows
-Fix GLib project/filter files generation as some source items are under
the "deprecated" subfolder, and filter out the gthread-*.c
-Explicitly specify gthread-win32.c in the GLib project/filter file
templates, since tarballs are done on Linux.
-Don't define g_static_mutex_get_mutex in the pregenerated
glibconfig.h.win32(.in) as it is defined in deprecated/gthread.h for Windows
We have a GDateTime test that compares the time now (as per the libc) to
the time now (as per GDateTime). The problem is that the time could
change between those two "now"s.
At Tracker we want to mmap files using O_NOATIME. With GMappedFile this is at
the moment impossible. For that reason I added the constructor new_from_fd to
the GMappedFile type.
https://bugzilla.gnome.org/show_bug.cgi?id=659754
This reverts commit c7f9cd17d446938aaf4126e0753302676f66fd22.
The old macros in gthread.h used this variable, so it must remain in
place to keep ABI compatibility.
Replace it with g_thread_create_with_stack_size() and a real function
implementation of g_thread_create().
Modify a testcase that was calling g_thread_create_full()
inappropriately (it was using the default values anyway).
This was ignored on Windows. On POSIX, where supported, it controlled
if we ended up with a proper system thread or a user-mode thread. Linux
did not support this.
Switch 'self' 'join' and 'create' from using the vtable to being called
via normal g_system_thread_* internal API (implemented in each of
gthread-{posix,win32}.c).
Again, we can put NULL in the vtable since these were never used from
gthread.h.
Thread priorities were already documented as not working on Solaris, and
they are meaningless on Linux unless the process separately requests
realtime scheduling (and even then, it appears only to work as root).
We can safely put a NULL into the vtable for set_priority since nothing
outside of gthread.c ever calls this (and that call is gone).
The "unknown reason" that the native thread implementation was broken is
because functions in kernel32.dll are (obviously) following Microsoft's
__stdcall ABI, not the GCC ABI.
Change our function pointers to be __stdcall pointers and change our
emulated implementation to match.
A pair of macros to define a constructor function (on compilers that
support such a concept) and to ensure that the function is run exactly
once (on compilers that lack such support).
Presently only GCC is implemented.
We remove the macros while at the same time switching all libglib users
from g_private_new() to g_private_init(). We deal with the strange
expectations of the libglib code that g_private_* should work before the
GPrivate has been initialised with a temporary shim.
- expose the structure types for GLib internal use only
- avoid infinite recursion hazards by ensuring that GPrivate never
calls back into any other part of GLib
- substantially rework the Windows implementation so that it never
holds locks, contains no arbitrary limits and doesn't waste
100*sizeof(void*) per thread
We have to keep the macro hacks for the time being since some code
inside libglib depends on it.
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
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
GStaticMutex makes use of atomic operations to initialise itself. We
were using GStaticMutex from the emulated case of gatomic. Use pthreads
directly to avoid unbounded recursion in this case.
This variable, which is the cause of much grief, exists for two reasons:
- ensuring the the wakeup pipe doesn't fill up
- preventing the first poll() after adding a source from waking up
immediately
The first point is no longer an issue with GWakeup.
The second point is addressed by using different logic: we only signal a
wakeup in the case that the context is currently acquired by a thread
that is not us.
As an added bonus, we can now implement g_main_context_wakeup() without
taking a lock.
https://bugzilla.gnome.org/show_bug.cgi?id=583511https://bugzilla.gnome.org/show_bug.cgi?id=320888
The boolean values to be returned by a GSourceFunc are always ambiguous,
and even in case of experienced developers then can lead to confusion.
The Perl bindings for GLib have two simple constants, mapping to TRUE
and FALSE, that make the return values less confusing: G_SOURCE_CONTINUE
and G_SOURCE_REMOVE respectively.
https://bugzilla.gnome.org/show_bug.cgi?id=631413
Remove the explicit thread initialisation functions for g_get_charset(),
g_get_filename_charsets() and g_get_language_names().
Add a lock around one remaining case of access to libcharset (the other
2 cases already have the lock).
Do a proper g_once_init_enter() style initialisation for the GLib
gettext functions.
https://bugzilla.gnome.org/show_bug.cgi?id=658683
Historically we've added random symbols to the public API with warnings
that they're private; examples are:
glib_gettext(), glib_pgettext()
g_thread_functions_for_glib_use, g_thread_use_default_impl, etc.
And we almost added "GWakeup" to public API just to share between glib and
gio.
This new glib__private__() API exports a hidden vtable, and adds a macro
GLIB_PRIVATE_CALL() that makes it generally convenient to use.
This adds an extremely tiny cost for the double indirection; but it has
the benefit that we don't need to either:
1) compile the code into both glib and gio (like GWakeup), with the
inefficiency that implies.
2) Export a "do not use this" symbol; the serious problem with this is
that someone CAN use it pretty easily. Particularly if we document
it. It's far, far harder to peek into a structure without a public
header file.
https://bugzilla.gnome.org/show_bug.cgi?id=657992
Since GMainLoop is now purely monotonic, it really doesn't make sense to
cache the wallclock time just for the sake of making a deprecated call
more efficient.
The first time this is called, this creates a GMainContext * and a
thread to run it. Future calls return the same. There are a lot of
places that we could use this in GLib.
g_thread_gettime() is an undocumented public function pointer that
points to a function that returns the monotonic time in nanoseconds.
g_get_monotonic_time() does the same in microseconds, so it can be used
instead.
GLib had one internal user in GFileMonitor that only cared about
millisecond accuracy; it has been ported to g_get_monotonic_time().
G_THREADS_ENABLED still exists, but is always defined. It is still
possible to use libglib without threads, but gobject (and everything
above it) is now guaranteed to be using threads (as, in fact, it was
before, since it was accidentally impossible to compile with
--disable-threads).
https://bugzilla.gnome.org/show_bug.cgi?id=616754
We had the 12 hour time format hard-coded to "%02d:%02d:%02d %s" but it
actually changes depending on the locale. Just with the other formats,
use nl_langinfo() if we have it, otherwise fall back on gettext().
Improve a few situations where g_date_time_format() was getting the
padding wrong when displaying alt digits (eg: Arabic numerals) for
formatting time.
We now depend on nl_langinfo (_NL_CTYPE_OUTDIGITn_WC) to do the
conversion, which is very likely glibc-specific, but our previous method
relied on a glibc-specific printf() feature, so no harm done there.
Add a configure check for nl_langinfo (_NL_CTYPE_OUTDIGITn_WC).
Uncomment a few testcases that were failing previously.
https://bugzilla.gnome.org/show_bug.cgi?id=658107
Explicitly mention C99's strftime() in the documentation for
g_date_time_format() as the one that we aim for compatibility with.
Specifically list the formats we do not support as well as the extra
ones that we borrow from glibc.
Test g_date_time_format() against strftime(). This test found quite a
few cases of incorrect behaviour on our part (fixes already committed
for those).
Our implementation of %W is incorrect. Nobody should want to use this
format anyway and the implementation is non-trivial, so rip it out
rather than fixing it.
Remove the testcase for %W as well.
