Commit Graph

93 Commits

Author SHA1 Message Date
Christoph Reiter
e13c646465 gcancellable: add back lost NULL check in g_cancellable_cancel()
Commit f975858e86 removed the NULL check in g_cancellable_cancel() by
accident which makes it crash when called with NULL.

Add the check back and add a test so this doesn't happen again.

Fixes #1710
2019-03-05 16:44:16 +01:00
Tomasz Miąsko
f975858e86 gcancellable: Synchronize access to cancelled flag
Synchronize access to cancelled flag of cancellable, which was
previously access without synchronization in g_cancellable_is_cancelled.
Use atomic operations instead of existing global mutex, to avoid
serializing calls to g_cancellable_is_cancelled across all threads.
2019-02-25 00:00:00 +00:00
Philip Withnall
79aead142f docs: Fix formatting of some literals and properties
Using `%` indicates that you’re linking to a symbol. In these cases we
wanted some nicely formatted literals, or a link to a specific property.
Use backticks for the literals, and link to the property fully.

Signed-off-by: Philip Withnall <withnall@endlessm.com>
2018-11-23 13:29:30 +00:00
Simon McVittie
7f3bfcb891 cancellable: Don't assert if finalization races with cancellation
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
2018-01-05 20:42:06 +00:00
Philip Withnall
8e8f4e6486 docs: Fix various minor syntax errors in gtk-doc comments
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
2017-11-07 14:51:12 +00:00
Sébastien Wilmet
3bf4a720c3 gio/: LGPLv2+ -> LGPLv2.1+
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
2017-05-29 19:53:34 +02:00
Philip Withnall
4091b2d19e gio: Drop redundant g_source_is_destroyed() calls
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
2017-03-23 15:00:19 +00:00
Christian Hergert
18a33f72db introspection: use (nullable) or (optional) instead of (allow-none)
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.
2016-11-22 14:14:37 -08:00
Philip Withnall
e966cc51de gcancellable: Mention nullability in g_cancellable_cancel() docs
Calling g_cancellable_cancel(NULL) is an explicitly allowed no-op, for
convenience. Document and annotate that.
2015-02-24 10:57:14 +00:00
Philip Withnall
203fe3b8a8 gcancellable: Clarify that GSources hold references to GCancellables
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
2014-10-27 09:43:55 +00:00
Matthias Clasen
de82b641b0 Add advice on g_cancellable_reset
Don't use it at home.
2014-10-06 22:41:06 -04:00
Evan Nemerson
570b27b9ac gio: port annotations from the Vala metadata.
https://bugzilla.gnome.org/show_bug.cgi?id=730493
2014-05-23 10:04:06 -07:00
William Jon McCann
20f4d1820b docs: use "Returns:" consistently
Instead of "Return value:".
2014-02-19 19:41:52 -05:00
Matthias Clasen
bc6ee788b4 docs: let go of &ast;
Since we are no longer using sgml mode, using /&ast; &ast;/ to
escape block comments inside examples does not work anymore.
Switch to using line comments with //
2014-02-14 21:33:36 -05:00
Matthias Clasen
adf892e96a Annotate all examples with their language
The C ones, at least.
2014-02-01 15:11:49 -05:00
Matthias Clasen
42cf80780b Docs: Big entity cleanup
Strip lots of entity use from |[ ]| examples (which are now
implicit CDATA). Also remove many redundant uses of <!-- -->.
2014-02-01 12:00:30 -05:00
Matthias Clasen
4d12e0d66f Docs: Don't use the emphasis tag
Most of the time, the text read just as well without the extra
boldness.
2014-01-31 20:34:33 -05:00
Daniel Mustieles
078dbda148 Updated FSF's address 2014-01-31 14:31:55 +01:00
Daiki Ueno
7e9e7a66a1 Fix documentation typos in GTask and GCancellable examples
https://bugzilla.gnome.org/show_bug.cgi?id=719884
2013-12-06 07:55:27 +09:00
Dan Winship
fff14a5b7c gcancellable: don't use g_cancellable_connect() in GCancellableSource
g_cancellable_connect() is documented as calling its callback only
once, but GCancellableSource should trigger every time the cancellable
is cancelled.

https://bugzilla.gnome.org/show_bug.cgi?id=710691
https://bugzilla.gnome.org/show_bug.cgi?id=711286
2013-11-11 09:28:07 -05:00
Ryan Lortie
c8aba61713 GCancellable: drop lock for callback during connect()
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
2013-10-29 10:49:48 -04:00
Ryan Lortie
6d08d1191b Revert "gcancellable: allow g_cancellable_disconnect from "cancelled" handler on same thread"
This reverts commits 83605e2d0a and
140fa7ee46.
2013-09-23 16:15:52 -04:00
Alexander Larsson
140fa7ee46 cancellable: Minor fix to docs
The code uses "my_data", not "data" everywhere else.
2013-09-23 09:11:04 +02:00
Ray Strode
83605e2d0a gcancellable: allow g_cancellable_disconnect from "cancelled" handler on same thread
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
2013-09-23 09:09:48 +02:00
Dan Winship
8d0e0c6fcc gcancellable: update GCancellableSource, fix a race condition
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
2013-07-13 16:38:55 -04:00
Dan Winship
1da47d5ede gsourceclosure: use g_cclosure_marshal_generic
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
2013-07-13 16:38:55 -04:00
Emmanuele Bassi
54cc43630d Rename the generated private data getter function
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.
2013-06-24 15:43:04 +01:00
Emmanuele Bassi
32747def4b gio: Use the new private instance data declaration
Use the newly added macros, and remove the explicit calls to
g_type_class_add_private().

https://bugzilla.gnome.org/show_bug.cgi?id=700035
2013-06-24 14:18:01 +01:00
Dan Winship
09c18537f4 g_cancellable_source_new: don't use a file descriptor
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
2012-07-17 15:32:48 -04:00
Robert Ancell
4143842eb4 Add missing allow-none annotations for function parameters.
Found using:
find . -name '*.c' | xargs grep 'or %NULL' | grep ' \* @' | grep -v '@error' | grep -v allow-none
2012-03-31 20:34:28 +11:00
Javier Jardón
8d3250016d gio: Use G_VALUE_INIT 2011-10-18 17:12:33 +01:00
Ryan Lortie
19cd57d4f3 GCancellable: use GCond and GMutex directly
Use a statically-allocated GCond and directly use GMutex instead of
making use of the undocumented G_LOCK_NAME() macro.

https://bugzilla.gnome.org/show_bug.cgi?id=660739
2011-10-04 11:13:46 -04:00
Matthias Clasen
34ce4dd032 Replace static privates by privates
GStaticPrivate is heading for deprecation soon, and GPrivate
can replace these uses now.
2011-10-02 22:11:33 -04:00
Ryan Lortie
cf26a6fc32 G_LOCK: port from GStaticMutex to GMutex
GCancellable made use of the undocumented G_LOCK_NAME macro in an
invalid way.  Fix that up while we're at it.
2011-09-21 15:55:36 -04:00
Colin Walters
9bf59d4a14 Add glib__private__() API to share between glib,gio; port GWakeup to it
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
2011-09-09 14:17:08 -04:00
Dan Winship
5a30712dc7 Remove !g_thread_supported() codepaths in gio
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
2011-09-09 12:47:39 -04:00
Matthias Clasen
1b28408b8b Spelling fixes
Spelling fixes in comments and docs, provided by
Kjartan Maraas in bug 657336.
2011-08-29 14:49:32 -04:00
Matthias Clasen
471593ebf0 GCancellable: Small annotation additions
https://bugzilla.gnome.org/show_bug.cgi?id=657243
2011-08-24 21:25:31 -04:00
Stef Walter
54579bf88f gio: GCancellable can be used concurrently
* 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
2011-08-19 11:13:37 +02:00
Owen W. Taylor
ee63179b71 g_cancellable_get_fd: silently return -1 for NULL cancellable
This keeps compatibility with previous behavior.

https://bugzilla.gnome.org/show_bug.cgi?id=655598

Signed-off-by: David Zeuthen <davidz@redhat.com>
2011-08-01 16:24:34 -04:00
Ryan Lortie
c81eb121a1 GWakeup: make it private API
Colin requests that we keep this one private for now.

Include it at each point of use (libglib, libgio, tests).
2011-07-25 18:51:03 +02:00
Ryan Lortie
0a971e46bf GCancellable: port to GWakeup 2011-07-25 15:30:35 +02:00
Colin Walters
182ed95861 GCancellable: Make eventfd() fall back to pipes on EINVAL too
https://bugzilla.gnome.org/show_bug.cgi?id=654232
2011-07-10 12:19:15 -04:00
Dieter Verfaillie
2456db2c00 GCancellable: Fix build on Win32
https://bugzilla.gnome.org/show_bug.cgi?id=653522
2011-06-30 09:32:32 -04:00
Colin Walters
315210ecdb GCancellable: Fix build on Win32
https://bugzilla.gnome.org/show_bug.cgi?id=653522
2011-06-28 12:52:58 -04:00
Colin Walters
fa87399280 GCancellable: Use Linux eventfd() instead of pipe
See commit f626dd2b4311bd82137c5b208ab2de288c3e6fae for rationale;
basically it's cheaper than a pipe.

https://bugzilla.gnome.org/show_bug.cgi?id=653140
2011-06-21 23:28:52 -04:00
Colin Walters
b74e2a720a Stop using glib-genmarshal at build time
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
2011-06-20 17:24:07 -04:00
Chun-wei Fan
9f90408e97 Update gcancellable.c for Win32
errno.h is still required for Windows in this file...
2011-05-05 13:40:38 +08:00
Colin Walters
542215b78a Rename g_unix_pipe_flags to g_unix_open_pipe
From IRC discussion, people liked this name more.

https://bugzilla.gnome.org/show_bug.cgi?id=649322
2011-05-03 23:34:17 -04:00
Colin Walters
c078223b38 GCancellable: Use g_unix_pipe_flags with FD_CLOEXEC
The old code was creating a pipe and setting FD_CLOEXEC
non-atomically.

https://bugzilla.gnome.org/show_bug.cgi?id=649225
2011-05-03 10:14:48 -04:00