It can cause failures for shared connection objects.
What can currently happen is this:
1. A user starts to asynchronously create a proxy object
2. A user starts to asynchronously create another proxy object
At this point, the asynchronous initialization for the two proxy objects
share the not yet initialized connection object.
3. While the shared connection objected is created, the user cancels the
creation with the supplied cancellable from the fist proxy object.
4. initable_init caches the canceled error and marks the connection as
initialized.
5. The initialization of the second proxy object fails with the same
canceled error.
To avoid this, clear the error in this case and destroy any member
variables that may have been created before the creation was canceled.
This way, the initialization of the second proxy object will restart the
connection initialization and with probably succeed.
Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
Before checking the properties of `*_proxy`, assert that there were no
errors in constructing the proxy first. Otherwise the property checks
will crash on `NULL` pointer dereferences.
The test is still intermittently buggy somewhere, but at least this
commit will cause a relevant error message to be printed on failure.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Just for debugging purposes, track whether the Connection Attempt Delay
(https://datatracker.ietf.org/doc/html/rfc8305#section-8) has been
reached for each attempt.
This makes it a bit easier to diagnose `GSocketClient` problems in a
debugger.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
This makes it match the terminology from RFC 8305 better, which refers
to a ‘connection attempt delay’. This is a delay because it determines
the spacing between trying additional connection attempts. It’s not a
timeout because it shouldn’t cause cancellation of any ongoing
connection attempts.
This commit introduces no functional changes.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
`TCP_NODELAY` disables Nagle’s algorithm, which is generally a better
default for modern networks than having it enabled. Nagle’s algorithm
delays sending small data blobs until they fill an entire TCP segment,
so as to amortise the cost of sending the segment.
This improves bandwidth at the cost of latency. Given the large
bandwidth capabilities of most modern networks, most streams are
constrained by latency rather than bandwidth, so disabling Nagle’s
algorithm makes sense.
Various other major bits of software (such as libcurl) already disable
Nagle’s algorithm by default.
Specific applications which need it can turn it back on by calling
`g_socket_set_option()`.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #791
As spotted by Michael Catanzaro in
https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3394#note_1730123,
on the code path where a `ConnectionAttempt` is cancelled, it will
currently be removed from the `connection_attempts` list by the
cancellation code, and then *again* by the `if
(task_completed_or_cancelled ())` code in
`g_socket_client_connected_callback()`.
That would previously have resulted in a double-unref of the
`ConnectionAttempt`. So change `connection_attempt_remove()` to be a
no-op if the attempt isn’t found in `connection_attempts`.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
These make it a bit easier to track the ongoing tasks, as the tasks
and/or their closures are not tracked in a big list somewhere.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
These calls are where the `GSocketClient` Happy Eyeballs code relies on
other components within GLib (and glib-networking) to complete
asynchronous operations in a timely manner. `GSocketClient` doesn’t add
its own timeouts to monitor these async operations, so if the
implementations are buggy then a `GSocketClient` operation could stall
forever.
Make that a bit clearer.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This introduces no functional changes, but makes it a little clearer
what the variable signifies, and provides a little more information when
debugging things.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
`P_()` is for pspec strings — it gave us the option to split them out to
a separate translation domain. `_()` is for normal strings.
Spotted by Sophie Herold: https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3411#note_1733329
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Nicks and blurbs don't have any practical use for gio/gobject libraries.
Leaving tests untouched since this features is still used by other libraries.
Closes#2991
Previously these properties would have been documented using the strings
from the pspec, but those will be removed in the following commit. Re-add
the documentation using those strings, but as gi-docgen documentation
comments.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #2991
In an attempt to make gobject-introspection stop warning about using
deprecated gtk-doc `Type:` tags.
It doesn’t work — the gobject-introspection parser is not clever enough
to notice the tag is inside a code block.
Still, a useful port.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3037
GDBus has always supported matching strings with arg0 matching
(`G_DBUS_SIGNAL_FLAGS_MATCH_ARG0_PATH`). In D-Bus 1.5, support was added
to the spec for also matching object paths. This got forgotten about and
was never added to GDBus, meaning that
`G_DBUS_SIGNAL_FLAGS_MATCH_ARG0_PATH` won’t match against a signal arg0
of type `o`.
Fix that, and add a unit test.
To do so, we need to add a new `g_dbus_message_get_arg0_path()` API to
complement the existing `g_dbus_message_get_arg0()` API. The approach of
letting `g_dbus_message_get_arg0()` return an object-path *or* a string
would not work, as it’s also called in the implementation of
`G_DBUS_SIGNAL_FLAGS_MATCH_ARG0_NAMESPACE`, which must only match
string-typed arg0 values and not object-path-typed ones.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3183
Technically we can’t rely on it being kept alive by the `message->body`
pointer, unless we can guarantee that the `GVariant` is always
serialised. That’s not necessarily the case, so keep a separate ref on
the arg0 value at all times.
This avoids a potential use-after-free.
Spotted by Thomas Haller in
https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3720#note_1924707.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3183
It was previously 4KiB, but this isn’t enough for sniffing the
content-type of some GPT disk images (they use 4KiB sectors, and the
magic bytes are in the second sector). A buffer of 8KiB would work,
but 16KiB seems harmless and more future proof.
Most of the time, the buffer size should be set by xdgmime anyway, based
on the largest sniff buffer its database needs. Currently (with
shared-mime-info master) that’s 18730 bytes, so even with a 16KiB buffer
we’re going to potentially mis-identify a few file types.
Tested manually by modifying the example GPT image from shared-mime-info
(https://gitlab.freedesktop.org/xdg/shared-mime-info/-/blob/master/tests/mime-detection/disk.gpt)
to remove the magic at offset 0x200 and add it instead at offset 0x1000,
then running:
```
cp shared-mime-info.git/tests/mime-detection/disk.gpt ./disk-without-extension
gio info -a standard::content-type ./disk-without-extension
```
It should print `application/vnd.efi.img` rather than
`application/octet-stream`.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3186
This fixes a stack overflow reported by a user who had both the
definition of text/javascript from shared-mime-info 2.3 and the
definition of text/javascript from shared-mime-info 2.4 installed at the
same time. In 2.3, text/javascript is a subtype of
application/ecmascript, but in 2.4 application/ecmascript is a subtype
of text/javascript. Having both at the same time resulted in circular
inheritance.
The new logic keeps a list of all parents that have already been
checked, which is more comprehensive than the old workaround that was
implemented in commit 38869ece2 ("xdgmime: Prevent infinite loops from
badly-formed MIME registrations").
https://bugs.archlinux.org/task/80279
This fixes a load of warnings about ‘multiple comment blocks documenting
<something> identifier’.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3037
Move it to a separate page, since it doesn’t quite make sense to
incorporate into the `GDBusConnection` docs.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3037
Move it to a separate page, as there isn’t a `GIOScheduler` struct.
Ensure that all its functions/methods/types are correctly marked as
deprecated. Fix a few broken links about I/O priority which pointed to
it.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3037
