delta/glib.git/gio/gcancellable.c, branch require-python34 gitlab.gnome.org: GNOME/glib.git cancellable: Don't assert if finalization races with cancellation 2018-01-05T20:42:06+00:00 Simon McVittie smcv@collabora.com 2017-12-19T10:58:32+00:00 7f3bfcb8912e9b8b2e73520857690356d91869b9 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 
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
docs: Fix various minor syntax errors in gtk-doc comments 2017-11-07T14:51:12+00:00 Philip Withnall withnall@endlessm.com 2017-11-07T13:38:58+00:00 8e8f4e6486c1578ae15d63835acd06f237324a6d 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 
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
gio/: LGPLv2+ -> LGPLv2.1+ 2017-05-29T17:53:34+00:00 Sébastien Wilmet swilmet@gnome.org 2017-05-27T16:21:30+00:00 3bf4a720c315b5015c8d51edf0b458348f796674 Sub-directories inside gio/ already processed in a previous commit: - fam/ - gdbus-2.0/ (which contains only codegen/) - gvdb/ - inotify/ - tests/ - win32/ - xdgmime/ Other sub-directories inside gio/: - completion/: no license headers - kqueue/: not LGPL, BSD-style license https://bugzilla.gnome.org/show_bug.cgi?id=776504 
Sub-directories inside gio/ already processed in a previous commit:
- fam/
- gdbus-2.0/ (which contains only codegen/)
- gvdb/
- inotify/
- tests/
- win32/
- xdgmime/

Other sub-directories inside gio/:
- completion/: no license headers
- kqueue/: not LGPL, BSD-style license

https://bugzilla.gnome.org/show_bug.cgi?id=776504
gio: Drop redundant g_source_is_destroyed() calls 2017-03-23T15:00:19+00:00 Philip Withnall withnall@endlessm.com 2017-02-05T15:34:54+00:00 4091b2d19e165ab9857ea4cd5ea296718540a4f8 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 
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
introspection: use (nullable) or (optional) instead of (allow-none) 2016-11-22T22:14:37+00:00 Christian Hergert chergert@redhat.com 2016-10-29T01:29:02+00:00 18a33f72db6a410606674d8d53fb2dadb706091d 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. 
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.
gcancellable: Mention nullability in g_cancellable_cancel() docs 2015-02-24T10:57:14+00:00 Philip Withnall philip.withnall@collabora.co.uk 2015-02-24T10:57:14+00:00 e966cc51de22a9f8b045f6f0f6f0de82f934d46d Calling g_cancellable_cancel(NULL) is an explicitly allowed no-op, for convenience. Document and annotate that. 
Calling g_cancellable_cancel(NULL) is an explicitly allowed no-op, for
convenience. Document and annotate that.
gcancellable: Clarify that GSources hold references to GCancellables 2014-10-27T09:43:55+00:00 Philip Withnall philip.withnall@collabora.co.uk 2014-09-24T13:06:02+00:00 203fe3b8a8817da8e1ec771e2ebd15c747653158 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 
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
Add advice on g_cancellable_reset 2014-10-07T02:41:06+00:00 Matthias Clasen mclasen@redhat.com 2014-10-07T02:41:06+00:00 de82b641b05ee32812d945a9d4ecd1c1bbc3401e Don't use it at home. 
Don't use it at home.
gio: port annotations from the Vala metadata. 2014-05-23T17:04:06+00:00 Evan Nemerson evan@nemerson.com 2014-05-21T07:27:36+00:00 570b27b9acbf6e6f31ab0f9a31a4cce60f4d228a https://bugzilla.gnome.org/show_bug.cgi?id=730493 
https://bugzilla.gnome.org/show_bug.cgi?id=730493
docs: use "Returns:" consistently 2014-02-20T00:41:52+00:00 William Jon McCann william.jon.mccann@gmail.com 2014-02-20T00:35:23+00:00 20f4d1820b8d4d0fc4447188e33efffd6d4a88d8 Instead of "Return value:". 
Instead of "Return value:".