This stack exists only to answer the question of "what is the currently
dispatching source" and is handled in a way that makes it very clear
that we don't need to be using a linked list at all...
Just store the GSource directly.
Independently discovered (and same solution) by Phillip Susi.
https://bugzilla.gnome.org/show_bug.cgi?id=709113
There are some corner cases where using the sync version of read/write
in a thread could cause thread-safety issues. In these cases it's
possible to override the output stream's splice_async() function,
but for input streams one would need to do some acrobatics to
stay thread-safe. Alternatively, some implementations may not even
override their sync read/write functions.
This patch refactors the default splice_async() implementation to
call the sync read and write functions in a thread only when both
async versions are thread-based. When one or both are non-threaded,
it calls the virtual write_async() and read_async() functions of the
involved streams within the same thread.
https://bugzilla.gnome.org/show_bug.cgi?id=691581
Refactor g_output_stream_close_async() into itself and an internal
variant for potential use inside other operations (splice_async).
The internal version must be called between
g_output_stream_set_pending() and g_output_stream_clear_pending().
https://bugzilla.gnome.org/show_bug.cgi?id=691581
Previously, no testcases tested the close flags of
g_output_stream_splice_async. This patch adds tests for that and
also tests various combinations of threaded and non-threaded
GInputStream async reads and GOutputStream async writes.
https://bugzilla.gnome.org/show_bug.cgi?id=691581
In implementing a better g_output_stream_splice_async() and possibly
other situtations it's helpful to know whether the output stream's
write function internally uses threads. If it and the input stream's
read async functions use threads, then the splice function could
spawn a single thread for better efficiency.
This patch adds a function to determine whether an output stream's
g_output_stream_write_async() function internally uses threads.
https://bugzilla.gnome.org/show_bug.cgi?id=691581
In implementing a better g_output_stream_splice_async() and possibly
other situtations it's helpful to know whether the input stream's
read function internally uses threads. If it and the output stream's
write async functions use threads, then the splice function could
spawn a single thread for better efficiency.
This patch adds a function to determine whether an input stream's
g_input_stream_read_async() function internally uses threads.
https://bugzilla.gnome.org/show_bug.cgi?id=691581
Rather than always calling out to g_file_get_path() (which
might block, whatever the documentation might say), postpone
the call until we actually need it.
https://bugzilla.gnome.org/show_bug.cgi?id=708753
Recent changes to the properties testcase made invalid use of the GArray
free function. This free function takes a pointer to the item to be
freed, not the item itself. Since that item was a pointer to a GObject,
g_object_unref() was getting a GObject**, rather than a GObject*.
The use of GArray in this testcase is pretty questionable in the first
place, so just use C arrays instead.
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
This commit adds a test to ensure that during a signal emission, if
a signal handler gets disconnected, it won't be run, even if it would
have run before the disconnection.
Apple's GCC compilers cannot deal well with 64-bit pointers in
transparent unions on ppc64, so compilation of
_G_DEFINE_BOXED_TYPE_BEGIN was failing. Fortunately glib already
provides a fallback for compilers that can't deal with it; this adds
this specific case to the check.
https://bugzilla.gnome.org/show_bug.cgi?id=647145
In the real_..._async wrapper for GFile.measure_disk_usage, skip the
wrapping of the progress callback in the case that the user gave a NULL
callback to the async function. This is a performance improvement
because the sync version won't have to do continuous sampling of the
clock to issue a call to the wrapper which will then do nothing.
Unfortunately, I made this simplifying assumption when writing the
wrapper, but forgot to actually implement it when making the sync call.
As a result, the wrapper is still called, and invokes the NULL callback,
causing a segfault.
Make sure we pass NULL if the user's callback was NULL.
https://bugzilla.gnome.org/show_bug.cgi?id=707787
