libinotify-kqueue is a library that implements inotify interface in terms of
kqueue/kevent API available on Mac OS and *BSD systems. The original kqueue
backend seems to be a predecessor version of the code that is currently present
in libinotify-kqueue. Under the hood the library implements a sophisticated
filesystem changes detection algorithm that is derived from the glib backend
code.
Updating the native glib kqueue backend requires substantial work, because code
bases have diverged greatly. Another approach is taken, instead. libinotify-kqueue
can serve as a drop-in replacement for Linux inotify API, thus allowing to
reuse the inotify backend code. The compatibility, however, comes at cost, since
the library has to emulate the inotify descriptor via an unix domain socket.
This means that delivering an event involves copying the data into the kernel
and then pulling it back.
The recent libinotify-kqueue release adds a new mode of operation called "direct".
In this mode the socket pipe is replaced with another kqueue that is used to
deliver events via a kevent(EVFILT_USER) call.
Employing the direct mode requires minor changes to the client code compared
to using plain inotify API, but in return it allows for reusing libinotify's
algorithms without a performance penalty. Luckily, all required changes are
consolidated in one file called inotify-kernel.c
This puts us in the best of possible worlds. On one hand we share a lot of code
with glib inotify backend, which is far more thoroughly tested and widely used.
On the other we support a range of non-Linux systems and consolidate the business
logic in one library. I plan to do the same trick for QFileSystemWatcher which
will give us the same behaviour between Gtk and Qt applications.
The glib test suite passes for both old kqueue backend and new libinotify-kqueue
one. However, the AppStream FileMonitor tests are failing with the old backend,
but pass with the new one, so this is still an observable improvement.
Relevant libinotify-kqueue PR: https://github.com/libinotify-kqueue/libinotify-kqueue/pull/19
The option defaults to 'auto' which keeps the current selection behavior, but
also allows user to override the choice.
Also make the chosen backend is reported to the code via CPP defines.
This introduces no functional changes, but does squash a false positive
warning from `-Wfloat-conversion`:
```
../gio/gapplication.c:462:15: error: implicit conversion turns floating-point number into integer: 'gdouble' (aka 'double') to '_Bool' [-Werror,-Wfloat-conversion]
if (*(gdouble *) entry->arg_data)
~~ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.
```
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
It’s a false positive, but points to a slightly unnecessary use of a
global variable to store something which could be computed per-test.
scan-build thought that arrays of size `n_handlers` could have
uninitialised values accessed in them if `n_handlers` were to change
value part-way through a test (which it didn’t).
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
These are typically files generated by the gobject-introspection dumper,
which we don’t want to scan as they are not part of GLib’s runtime code.
For example:
```
/builds/GNOME/glib/_scan_build/meson-private/tmpr3jwvyib/tmp-introspect5dmnb_je/GObject-2.0.c:799:27: warning: Access to field 'message' results in a dereference of a null pointer (loaded from variable 'error') [core.NullDereference]
799 | g_printerr ("%s\n", error->message);
| ^~~~~~~~~~~~~~
1 warning generated.
```
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes commit 93271385f9.
Previously the `before_script` from `.build-linux` was used in whole for
these two jobs, but since the `.build-gobject-introspection` template
was also added, the `before_script`s from the two templates need to be
explicitly combined.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3458
Remove cmake as we no longer need to build ninja. We can use the
official wheel now since the runner's Python is 3.9 (before: 3.8).
Use the same comment regarding '--wrap-mode' as in the other jobs.
Download and use official ccache binary.
Add myself to the 'only' section in .gitlab-ci.yml so I can have
CI in my fork.
Disable a few deprecation warnings due to the much newer SDK of
the Apple Silicon machine.
Meson 1.5.1 is available in the fd.o SDK and in Debian testing, so the
glib Meson policy says we can update. Update the minimum only as far as
1.4.0 because we don't yet have a need for 1.5.0.
This allows us to:
- Use file.full_path() to avoid deprecation warnings on str.format(file).
- Set c_std=gnu99,c99 to avoid deprecation warnings with gnu99 on MSVC.
Update all the CI builds to use the latest 1.4.x patch release, 1.4.2.
The FreeBSD runner cannot be updated via `gitlab-ci.yml`, so will be
broken for now.
Similarly, the macOS build will not work unless `-Dc_std=gnu99` is
specified at configure time, due to
https://github.com/mesonbuild/meson/issues/13639.
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