Commit 281e3010 narrowed the race between GCancellable::cancelled and
GCancellableSource's finalize(), but did not prevent it: there was
nothing to stop cancellation from occurring after the refcount drops
to 0, but before g_source_unref_internal() bumps it back up to 1 to
run finalize().
GCancellable cannot be expected to detect that situation, because the
only way it has to detect last-unref is finalize(), but in that
situation finalize() hasn't happened yet.
Instead of detecting last-unref, relax the precondition a little
to make it detect finalization: priv is only poisoned (set to NULL)
after the finalize() function has been called, so we can assume that
GCancellable has already seen finalize() by then.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=791754
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=884654
This will fix a few broken links in the documentation, and shut up a
load of gtk-doc warnings (but certainly not all of them).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=790015
These calls cause race warnings from tsan, but are not a thread safety
problem, because we can only ever observe single bit changes: all
modifications to the GSource.flags field are done with a lock held; all
reads are of independent fields, so no intermediate state can ever be
observed. This assumes that a non-atomic read will consistently give us
an old value or a new value.
In any case, these g_source_is_destroyed() calls can happen from any
thread, and the state could be changed from another thread immediately
after the call returns; so the checks are pointless. In addition,
calling g_source_set_ready_time() or g_source_destroy() on a destroyed
source is not a problem.
https://bugzilla.gnome.org/show_bug.cgi?id=778049
If we have an input parameter (or return value) we need to use (nullable).
However, if it is an (inout) or (out) parameter, (optional) is sufficient.
It looks like (nullable) could be used for everything according to the
Annotation documentation, but (optional) is more specific.
Clarify in the documentation that a GSource created with
g_cancellable_source_new() must be explicitly removed from its
GMainContext before the GCancellable can be finalised.
This could be a common way of leaking GCancellables.
https://bugzilla.gnome.org/show_bug.cgi?id=737259
Since we are no longer using sgml mode, using /* */ to
escape block comments inside examples does not work anymore.
Switch to using line comments with //
Don't hold the lock when calling the user's callback during
g_cancellable_connect() for the case that the cancellable has already
fired.
Taken from a patch by Alex Larsson.
Doc updates from Colin Walters.
https://bugzilla.gnome.org/show_bug.cgi?id=705395
g_cancellable_disconnect will wait until any pending "cancelled"
handlers finish. This is useful because disconnecting a handler can have the
side-effect of freeing data that the cancelled handler may rely on.
Unfortunately, the code used to enforce this synchronization between
"cancelled" handlers and g_cancellable_disconnect will also cause
deadlock if the cancelled handler itself calls g_cancellable_disconect.
Obviously, if g_cancellable_disconnect is explicitly called by a "cancelled"
handler, then the "cancelled" handler is shouldering the responsibility
of not using any data that may be freed by disconnection.
Also, g_cancellable_disconnect can be called in unexpected places by
lower layers in the code (for instance as a result of g_source_destroy).
In practice, this means it's easy for deadlocks to inadvertently crop
up when using "cancelled" handlers.
For these reasons, it would be good to fix the deadlock.
This commit prevents the deadlock by allowing foregoing synchronization,
if a pending "cancelled" handler is in the same thread as the
g_cancellabale_disconnnect call.
https://bugzilla.gnome.org/show_bug.cgi?id=705395
Update GCancellableSource to call g_source_set_ready_time() when its
cancellable is cancelled, rather than manually checking the state of
the cancellable from prepare() and check().
This means that we now need to use g_cancellable_connect() rather than
g_signal_connect() at construction time, to avoid the connect/cancel
race condition. Likewise, use g_cancellable_disconnect() to avoid the
disconnect/cancel race condition when freeing the source. (In fact,
that was necessary in the earlier code as well, and might have
occasionally caused spurious criticals or worse.)
https://bugzilla.gnome.org/show_bug.cgi?id=701511
For the glib-defined source types, and any source type that defines a
closure callback but not a closure marshal, use
g_cclosure_marshal_generic. And then remove all the other remaining
source closure marshals.
https://bugzilla.gnome.org/show_bug.cgi?id=701511
As it turns out, we have examples of internal functions called
type_name_get_private() in the wild (especially among older libraries),
so we need to use a name for the per-instance private data getter
function that hopefully won't conflict with anything.
Rather than implementing GCancellableSource by polling on its fd,
implement it by just waking its GMainContext up from the "cancelled"
signal handler, thereby helping to reduce file descriptor usage.
Suggested by Ryan Lortie.
https://bugzilla.gnome.org/show_bug.cgi?id=680121
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
In particular, remove the libasyncns import, which was only used by
GUnixResolver, which is only used when threads are not available.
Likewise remove GWin32Resolver, and the hacky broken non-threaded
parts of GIOScheduler.
https://bugzilla.gnome.org/show_bug.cgi?id=616754
* Update documentation to note that GCancellable can be used
concurrently by multiple operations.
* Add documentation to g_cancellable_reset that behavior is
undefined if called from within cancelled handler.
* Add test for multiple concurrent operations using the same
cancellable.
https://bugzilla.gnome.org/show_bug.cgi?id=656387
To help cross compilation, don't use glib-genmarshal in our
build. This is easy now that we have g_cclosure_marshal_generic().
In gobject/, add gmarshal.[ch] to git (making the existing entry
points stubs).
In gio/, simply switch to using g_cclosure_marshal_generic().
https://bugzilla.gnome.org/show_bug.cgi?id=652168
g_cancellable_create_source() returns a GSource that triggers when its
corresponding GCancellable is cancelled. This can be used with
g_source_add_child_source() to add cancellability to a source.
Port gasynchelper's FDSource to use this rather than doing its own
cancellable handling, and also fix up its callback argument order to
be more normal.
https://bugzilla.gnome.org/show_bug.cgi?id=634239
