Alpine 3.19 ships with Meson 1.3.0, which has broken handling of File
objects and their paths. This causes (as far as I can tell)
un-work-around-able breakage of GLib’s build.
See https://github.com/mesonbuild/meson/issues/5273#issuecomment-1851811417
That should be fixed in Meson 1.4.0, but that might not be released for
a while. Because we’re here to test GLib, not Meson, let’s pin the Meson
version in the Alpine CI image to 1.2.3, which we know works and is
reasonably up to date (and is what the other CI images use).
Fixes this CI failure: https://gitlab.gnome.org/GNOME/glib/-/jobs/3361388
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
This is just the result of running `black $(git ls-files '*.py')`.
For some reason, the `sh-and-py-check` CI job didn’t run on merge
request !3751, so this non-standard formatting slipped through onto
`main`.
See https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3754#note_1939914
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
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>
There is no reason for key and value to have different annotations.
Both may return NULL as a valid value.
gpointer typed parameters are nullable by convention, so there is
no change here. The (nullable) annotation is just for humans really.
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
