It’s not particularly clear why both these exist and why you need to use
both of them when creating a `GValue` — but you do.
Try and clarify things in the documentation.
In particular, replace use of the term ‘uninitialised’ (referring to a
`GValue` which has been set to `G_VALUE_INIT` but not yet had
`g_value_init()` called on it) with ‘zero-filled (cleared)’ instead.
‘uninitialised’ doesn’t make sense to describe a variable which, in C
terms, has just been initialised by assigning `G_VALUE_INIT` to it.
‘cleared’ is a bit less overloaded as a term.
Add some code examples to hopefully make things clearer too.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Development versions of glib like 2.85.2 produce library files with
names like "libglib-2.0.so.0.8502.0" whereas stable version names
are like "libglib-2.0.so.0.8400.2".
The produced stp files for SystemTap work for stable versions but not
for development versions.
Fix this by passing the correct variables into LT_CURRENT and
LT_REVISION.
Based on my reading of the docs, g_spawn_async_with_pipes_and_fds()
seems to have a much more comprehensive explanation of itself than
g_spawn_async_with_pipes(). As such, it makes sense to me to refer to it
rather than the latter when suggesting where to go for further reading.
Signed-off-by: Stefan Hansson <newbyte@postmarketos.org>
If g_ascii_strtoll does not use strtoll_l, the result of
g_parse_long_long could be G_MININT64 with gboolean negative set.
In such a case, returning `- (gint64) result` would lead to an undefined
behavior because -G_MININT64 would lead to an implicit integer overflow.
Realistically though, this still leads to G_MININT64. Fixes test failure
if compiled with ubsan on a platform without strtoll_l.
Some GByteArray functions already pass through the return values of
called GArray functions. Do so for all functions so callers might
react to errors and for consistency.
The Meson test harness handles that for us.
With a custom timeout, meson test -t is not useful (which is
surprising for users) and interactive debugging sessions may
terminate unexepectedly.
Make sure that arguments are not null. While internal functions are
properly protected, the code execution continues and eventually leads
to a NULL pointer dereference.
It’s possible for the server communications to finish one main context
iteration before all of the client communications, depending on how the
kernel queues socket connection messages.
Fixes CI failure: https://gitlab.gnome.org/GNOME/glib/-/jobs/5341950
```
GLib-GIO:ERROR:../gio/tests/socket-listener.c:639:test_accept_multi_simultaneously: 'clients[i].result' should not be NULL
not ok /socket-listener/accept/multi-simultaneously - GLib-GIO:ERROR:../gio/tests/socket-listener.c:639:test_accept_multi_simultaneously: 'clients[i].result' should not be NULL
```
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
As the new comments in the code try to explain, this fixes infinite
blocking which could happen when calling
`g_socket_listener_accept_async()` multiple times in parallel, with more
parallel calls than there are pending incoming connections on any of the
`GSocket`s in the `GSocketListener`.
The way `g_socket_listener_accept_async()` works is to create a set of
`GSocketSource`s when it’s called, one for each of the `GSocket`s in the
`GSocketListener`. Those sources are attached to the main context,
polling for `G_IO_IN` (indicating that the socket has a pending incoming
connection to accept).
When one of the socket sources polls ready, `g_socket_accept()` is
called on it, and a new connection is created.
If there are multiple pending `g_socket_listener_accept_async()` calls,
there are correspondingly multiple `GSocketSource` sources for each
`GSocket` in the `GSocketListener`. They will all poll ready in a single
`GMainContext` iteration. The first one to be dispatched will
successfully call `g_socket_accept()`, and subsequent ones to dispatch
will do likewise until there are no more pending incoming connections.
At that point, any remaining socket sources polling ready in that
`GMainContext` iteration will call `g_socket_accept()` on a socket which
is *not* ready to accept, and that will block indefinitely, because
`GSocket` has its own blocking layer on top of `poll()`.
This is not great.
It seems like a better approach would be to disable `GSocket`’s blocking
code, because `GSocketListener` is using `poll()` directly. We only need
one source of poll truth. So, do that.
Unfortunately, that’s complicated by the fact that
`g_socket_listener_add_socket()` allows third party code to provide its
own `GSocket`s to listen on. We probably can’t unilaterally change those
to non-blocking mode, so users of that API will get what they ask for.
That might include blocking indefinitely. I’ve adjusted the
documentation to mention that, at least.
The changes are fairly simple; the accompanying unit test is less
simple. Shrug. It tests for the scenario fixed by this commit, plus the
scenario fixed by the previous commit.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3739
The changes in commit 30ccfac9cf were not quite correct. The code is
structured so that a single reference to a `GTask` (and hence its
`AcceptSocketAsyncData` task data) is shared across the multiple
`GSocketSource`s which are created for a pending `accept_async()` call.
Setting `returned_yet` to true to short-circuit the remaining
`accept_ready()` dispatches in a given `GMainContext` iteration would
have worked, were it not for the fact that the code then immediately
dropped the last reference it had to the `GTask`, potentially freeing
the structure which contained `returned_yet`. Because of the async
nature of `GTask`, the exact timing of finalisation could vary.
This also meant that the other `GSocketSource`s were not destroyed until
an unknown time later.
Improve on that by explicitly destroying the other `GSocketSource`s as
soon as the first one returns an accepted socket. This causes
`GMainContext` to skip dispatching them, even within the same
`GMainContext` iteration. It also means the separate `returned_yet`
member is unnecessary.
This should fix the immediate issue seen in #3739. However, while
testing it I found a further issue which will be fixed in a following
commit, before I add a unit test.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3739
