The start of the `g_file_copy()` implementation stats the source file to
find all the attributes to copy onto the destination file, so it makes
sense to get it to store the source file size at the same time.
This saves a subsequent `stat()` call on the source FD in the btrfs
reflink or splice code. Every little helps.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Something has changed recently which causes this error to now be emitted
when building on Windows msys2-mingw32:
```
../gio/gwin32networkmonitor.c: In function 'win_network_monitor_get_ip_info':
../gio/gwin32networkmonitor.c:92:15: error: storing the address of local variable 'prefix' in '*dest' [-Werror=dangling-pointer=]
92 | *dest = (guint8 *) &prefix.Prefix.Ipv4.sin_addr;
| ~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```
If `IP_ADDRESS_PREFIX` is defined as a scalar rather than a pointer,
that could explain the problem.
Change the function to always operate on a pointer to avoid any
potential such issues.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This should hopefully stop the kernel spending a lot of memory and disk
bandwidth creating coredumps for them unnecessarily, which slows down
the rest of the tests and generally wastes resources.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2939
This is put together through git archaeology:
```
git log -- glib/tests/assert-msg-test.c tests/assert-msg-test.c
```
The following commits were too trivial to have meaningful copyright:
- 8e59d8602c
- 44c004c84e
- 207b8cb8a5
- a1bee97d4f
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1415
I’ve finally found the right place in the docs to put this stuff.
This doesn’t auto-link this section from every string in the GLib
documentation, but I think that at this point (with gtk-doc in
maintenance mode, and gi-docgen not fully applied to GLib) I don’t think
we can do any better. The perfect is the enemy of the good, and having
this stuff documented somewhere means that someone can link to it from
multiple places in future *somehow*.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #116
Apparently 3 hashes is too many, and as a result this line is not
displayed properly in the HTML documentation. 2 hashes seems to be
just right, as can be seen with:
$ git grep '^ \* ##' | wc -l
65
$ git grep '^ \* ###' | wc -l
1
The gio/tests/socket-client.c doesn't use GSocketClient, which makes the
filename confusing. What the file actually tests is the GSocket. Rename
it to socket-testclient.c
The corresponding GSocket server test file naming doesn't conflict with other
class names, but rename it to socket-testserver.c for consistency.
Closes#2855
Otherwise it might look like it would only start spawning threads when
jobs are enqueued.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2958
By default, if a host environment has the `rst2html5` application
available, builds will automatically perform some HTML documentation
generation from the documentation's glib reference content (e.g.
creating `gvariant-specification-1.0.html`). The creation of this
documentation is not required for all use cases.
This commit tweaks the building of the HTML-based GLIB specification
document to be guarded by `gtk_doc`.
Signed-off-by: James Knight <james.d.knight@live.com>
Most of the document was about traps, which have not existed since
commit 58cdf0b474, 10 years ago.
The rest of the document was about `GOBJECT_DEBUG`, and that information
would be more easily findable in the full GObject documentation — so
move it there and update it a bit.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The file was not listed in `POTFILES.in` (as pointed out by Piotr Drąg
in
fee0a7679a (note_1722885)),
so either it needs to be added to `POTFILES.in` or the translatable
strings need to be removed.
Recent prior art from GTK shows that there’s actually no longer any
point in setting the nick/blurb as no tools use them (and if they did,
it would result in a rubbish user experience). See
https://gitlab.gnome.org/GNOME/gtk/-/issues/4904.
Hence, drop the strings entirely.
See #2991 for tracking this across all of GIO.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2991
If you’re only quickly looking at the API signature, it looks like
`item_free_func` will be called for all items enqueued to the thread
pool.
As it happens, it’s actually only called for the items which are still
enqueued when the thread pool is destroyed. The user’s `GFunc` is
responsible for freeing items which are successfully dequeued and
processed during the lifetime of the thread pool.
That’s a bit of a gotcha, so document it more explicitly.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
If a timeout executes on the same main context iteration as completion
or cancellation of a resolver lookup, `has_returned` will be set
multiple times. That’s fine (the `GCond` will be notified multiple
times, but that’s fine). It was triggering an incorrect assertion, so
remove that.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The default for the class is still to have no timeout, but it seems more
practical for most use cases to set a non-infinite timeout on the
default resolver.
If applications have a more specific use case, they can change the
timeout or replace the default resolver.
See https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3397#note_1731387
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
If `async_cancel()` was invoked, it would remove the IO watch source,
which would cause the `g_source_remove()` call at the end of `main()` to
warn about an unknown source ID.
Fix that by handling the source as a pointer instead of a handle.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Rather than running lookups in the global shared thread pool belonging
to `GTask`, run them in a private thread pool.
This is needed because the global shared thread pool is constrained to
only 14 threads. If there are 14 ongoing calls to
`g_task_run_in_thread()` from any library/code in the process, and then
one of them asks to do a DNS lookup, the lookup will block forever.
Under certain circumstances, particularly where there are a couple of
deep chains of dependent tasks running with `g_task_run_in_thread()`,
this can livelock the program.
Since `GResolver` is likely to be called as a frequent leaf call in
certain workloads, and in particular there are likely to be several
lookups requested at the same time, it makes sense to move resolver
lookups to a private thread pool.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
