The WSAEnumNetworkEvents API is called every time the socket
needs to be checked for status changes. Doing this in an application
with several sockets could generate a high cpu usage since
this call is done for each socket at each iteration of the main loop.
Since there is also a WSAEvent that gets signaled when there is
a change in the status of the socket, checking its status and
calling the WSAEnumNetworkEvents API only if the event is signaled,
can reduce the overall cpu usage.
This was one of the code paths not currently covered by unit tests, so
let’s add a test for it.
This tests what happens when a structurally valid GResource file, but
with a corrupt entry for a compressed file, is loaded.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3465
This is slightly more involved than the previous couple of commits, as
`g_resource_lookup_data()` can return two errors: one if the resource is
not found, and another if decompression fails.
We want to avoid allocating the `G_RESOURCE_ERROR_NOT_FOUND` error, as
`g_resources_lookup_data()` will be looping through multiple
`GResource`s trying to find the given path, and all but one of them will
return `G_RESOURCE_ERROR_NOT_FOUND`. For a large application, this can
amount to a lot of `GError`s allocated and then immediately freed on
startup.
Use the split from the previous commit to replace the call to
`g_resource_lookup_data()` with its two constituent parts. We can then
handle errors from them separately, ignoring the `NOT_FOUND` error from
`do_lookup()`, while paying attention to any errors from
`resource_to_bytes()`.
This should result in no functional difference to
`g_resources_lookup_data()`, but fewer allocations overall.
Spotted by Christian Hergert.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3465
The value returned when generating a collation key is an opaque binary
blob that is only meant to be used for byte-wise comparisons; we should
not imply it's a nul-terminated, UTF-8 string.
This is especially true for language bindings that try to convert C
strings returned by GLib into UTF-8 encoded strings.
Ideally, the collation functions should return a byte array, but the
closest thing we have is the OS native encoding type that we use for
paths and environment variables.
See: https://github.com/gtk-rs/gtk-rs-core/issues/1504
It’s now a call to `do_lookup()` followed by a call to
`resource_to_bytes()`. This makes no functional changes, but will be
useful in the following commit.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3465
As with the previous commit:
The error here can only ever be `G_RESOURCE_ERROR_NOT_FOUND`, which
`g_resources_get_info()` immediately frees. So let’s avoid allocating
the error in the first place.
Spotted by Christian Hergert.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3465
The error here can only ever be `G_RESOURCE_ERROR_NOT_FOUND`, which
`g_resources_open_stream()` immediately frees. So let’s avoid allocating
the error in the first place.
Spotted by Christian Hergert.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3465
This makes it a bit easier to make sure all the translatable strings are
kept in sync. It introduces no functional changes.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3465
When the child process is going to exit on error after fork() but before
exec(), let's close the child_err_report_fd. The practical value of this
is to placate valgrind --track-fds=yes.
