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 the GLIB_AVAILABLE_IN_ALL annotation to all old functions (that
haven't already been annotated with the GLIB_AVAILABLE_IN_* macros or a
deprecation macro).
If we discover in the future that we cannot use only one macro on
Windows, it will be an easy sed patch to fix that.
https://bugzilla.gnome.org/show_bug.cgi?id=688681
The very last access to the 'depth' field of GStaticRecMutex in
g_static_rec_mutex_unlock_full() was being performed after dropping the
implementation mutex for the last time.
This allowed the lock to be dropped an additional time if it was
acquired in another thread right at that instant (which is somewhat
likely, since another thread could have just been woken up by the lock
being released).
https://bugzilla.gnome.org/show_bug.cgi?id=670846
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
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.
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().
...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.
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.
