GitLab

These would only happen if the API contract of the write() and writev()
functions was broken by subclasses.

This comes with default implementations around the normal write
functions and async variants.

Fixes #1431

If flush_async is deleted by a child class, then calling
g_output_stream_flush_async would leave the GOutputStream in an invalid
state. I'm not aware of any GOutputStream that would be affected by this
issue, but might as well fix it.

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

Spotted by Izak van Langevelde.
Signed-off-by: Philip Withnall <withnall@endlessm.com>

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

Signed-off-by: Philip Withnall <withnall@endlessm.com>

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

"ouput" -> "output" (missing 't')
"asyncronous" -> "asynchronous" (missing 'h')

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

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.

See https://developer.gnome.org/hig/stable/typography.html

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

This makes them easier to identify when debugging and profiling.

This patch was somewhat less than interesting to write.

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

Specifically, GIOStream and the TLS connection streams.

Includes wording adapted from suggestions by Dan Winship
<danw@gnome.org>.

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

When G_OUTPUT_STREAM_CLOSE_TARGET is set,
g_output_stream_real_splice was not returning -1 in any error
cases, since the success flag was being overwritten.

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

Add an internal helper to find out if close_async() is implemented via
threads using the default implementation in the base class.

We will use this to decide if we should do a 'pure async' close of a
GIOStream or not.

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

Remove the /** **/-style block from two internal helpers to prevent
gtk-doc from picking them up.

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

These functions are inconsistent with our normal conventions in that
they set an output variable to a specified value, even in the case that
an error is thrown.

Document very clearly that this should be considered exceptional.

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

Similar to the previous patch, this commit contains a minor violation of
normal API conventions.  See the explanation in the previous commit
message.

Heavily based on a patch from Ignacio Casal Quinteiro.

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

Instead of "Return value:".

Most of the time, the text read just as well without the extra
boldness.

More markup removal

Usually async methods copy/ref its arguments so caller can
forget about them. g_file_replace_contents_async() and
g_output_stream_write_async() are exceptions.

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

because we call g_output_stream_vprintf() which does exactly the same
checks.

which are useful for porting FILE* based output code.

Matthew Barnes noted this on IRC a few days ago.  I just had this file
open for other reasons and decided to tweak the docs to make this trap
more clear.

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

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

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

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.

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

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

Rather than doing a two step first-check-the-GAsyncResult-subtype-then-
check-the-tag, add a GAsyncResult-level method so that you can do them
both at once, simplifying the code for "short-circuit" async return
values where the vmethod never gets called.

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

Finish deprecating the "handle GSimpleAsyncResult errors in the
wrapper function" idiom (and protect against future GSimpleAsyncResult
deprecation warnings) by adding a "legacy" GAsyncResult method
to do it in those classes/methods where it had been traditionally
done.

(This applies only to wrapper methods; in cases where an _async
vmethod explicitly uses GSimpleAsyncResult, its corresponding _finish
vmethod still uses g_simple_async_result_propagate_error.)

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

Originally, the standard idiom with GSimpleAsyncResult was to handle
all errors in the _finish wrapper function, so that vmethods only had
to deal with successful results. But this means that chaining up to a
parent _finish vmethod won't work correctly. Fix this by also checking
for errors in all the relevant vmethods. (We have to redundantly check
in both the vmethod and the wrapper to preserve compatibility.)

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

Using a caller-supplied buffer for g_input_stream_read() doesn't
translate well to the semantics of many other languages, and using a
non-refcounted buffer for read_async() and write_async() makes it
impossible to manage the memory correctly currently in
garbage-collected languages.

Fix both of these issues by adding a new set of methods that work with
GBytes objects rather than plain buffers.

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

g_output_stream_write_async() was not initializing the newly-added
members of the WriteData structure, causing various problems.

Also, g_input_stream_read_async() was now leaking its cancellable. Fix
that as well.

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

If a GInputStream does not provide a read_async() implementation, but
does implement GPollableInputStream, then instead of doing
read-synchronously-in-a-thread, just use
g_pollable_input_stream_read_nonblocking() and
g_pollable_input_stream_create_source() to implement an async read in
the same thread. Similarly for GOutputStream.

Remove a bunch of existing read_async()/write_async() implementations
that are basically equivalent to the new fallback method.

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