Since we cannot use GOBJECT_VAR, and we don't have a way to add
caller-specific annotations, we default to making the gtype_id global
visible by default everywhere.
Instead of forcing the call to the get_type() function to get a GType,
we can introduce a global variable when using G_DECLARE_* and G_DEFINE_*
macros, and wrap its access with a generated static inline.
The variable is set under a once-time lock when calling the get_type()
function, and it is read atomically. If the global variable is unset, we
call the get_type() function, which will set the variable for
subsequent calls.
Feature test macros always need to be defined before any headers are
included. This triggers a redefinition warning with GCC 16 and the new
gnu11 C level.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
g_bus_unown_name() calls ReleaseName synchronously after checking that
the connection is still open. However, the connection can close on the
worker thread between the check and the call, which commonly happens
during session shutdown when the bus daemon exits while clients are
still running cleanup code.
When this race occurs, the ReleaseName call fails with G_IO_ERROR_CLOSED
and produces a spurious warning in the journal. Downgrade to g_debug
since the name release is best-effort — the bus daemon is gone, so the
name is already unowned.
The behaviour has to be this way, if users think for a minute about how
pipes/sockets/FDs work (one end does not get a notification that the
other end has closed them without doing a read/write).
However, that’s not at all hinted at by the documentation, so let’s add
something to clarify that for people who are in a hurry.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
...and Visual Studio-style builds. These builds do not build DLLs with a
'lib' prefix, and therefore the test would fail as a 'lib' prefix is
expected.
Check in the script whether we are running in a MSVC-style environment,
by checking the envvars that the various vcvars*.bat's, which is used
to setup a Visual Studio command prompt, set.
On AIX, poll.h must be included before other GLib headers to
avoid build failures.
The fix was required because of this commit: 42283ffb
After the above commit, "glib.h" started being included before <poll.h>.
This was also discussed in !4355 (merged). The root cause was the include order in gmain.c:
gmain.c -> glib-unix.h -> glib.h -> giochannel.h -> gmain.h -> gpoll.h
However, <poll.h> was being included only after glib-unix.h in gmain.c, which caused the issue.
To resolve this, we moved the #include <poll.h> directive to the beginning of the file.
This implements the fix discussed in:
https://gitlab.gnome.org/GNOME/glib/-/work_items/3500
The construction dump sent a bare `rtgenmsg` `RTM_GETROUTE`, which the
kernel answers through the non-strict path with route-cache exceptions
included (cloned PMTU and redirect routes). On a host with large route
tables those clones are numerous and churn constantly, which has two
costs: the dump walks far more entries, and every clone change bumps the
IPv6 FIB generation, so the kernel restarts the IPv6 dump from the root
over and over (`fib6_dump_table()`) and one dump request balloons into
dozens of re-walks. On a full-table BGP router this made the dump ~30x
larger than the table and tens of seconds long, against ~3s for `ip route
show table all`.
Enable `NETLINK_GET_STRICT_CHK` and send an `rtmsg`: under strict checking
the kernel reads `rtm_flags` and, with `RTM_F_CLONED` unset, leaves the
cache exceptions out of the dump (`dump_exceptions = false`), returning FIB
routes only. This is how iproute2 issues route dumps. The option is
feature-detected and its failure is non-fatal, falling back to the heavier
dump.
The setsockopt level `SOL_NETLINK` is defined in the kernel's
`<linux/socket.h>`, not the uapi `<linux/netlink.h>` that provides
`NETLINK_GET_STRICT_CHK`, so an older libc can expose the option constant
without the level. Define it as a fallback, matching iproute2
(`lib/libnetlink.c`).
Signed-off-by: Sorah Fukumori <her@sorah.jp>
The route-monitor socket used the default receive buffer (net.core.rmem_default,
typically ~208 KiB). On a host with a large or busy routing table the
initial dump and the stream of unsolicited route changes can overrun it,
which surfaces as ENOBUFS and forces a full re-dump to resync.
Request a 1 MiB receive buffer on the netlink sockets, as iproute2 does
unconditionally in `rtnl_open_byproto()`. The kernel clamps the request to
net.core.rmem_max, so this is best-effort for an unprivileged process, but
it matches the headroom every other rtnetlink client runs with.
Signed-off-by: Sorah Fukumori <her@sorah.jp>
The route-monitor socket sized each read to the exact length of the next
datagram, learned with an MSG_PEEK probe, and allocated that much. The
kernel grows route-dump datagrams only up to the largest buffer the socket
has ever been read with (`nlk->max_recvmsg_len`, see
`net/netlink/af_netlink.c`), so reading exact-sized buffers keeps that
ceiling at one page and forces a full-table dump to arrive in ~4 KiB
datagrams, an order of magnitude more datagrams and syscalls than `ip
route` (which reads into a fixed 32 KiB buffer).
Read into a single buffer sized at `NETLINK_MESSAGE_MAX_SIZE` instead. The
kernel then packs the dump into its 32 KiB datagram ceiling, and the
MSG_PEEK round-trip per datagram is gone. `MSG_TRUNC` guards the
theoretical oversized datagram, which the generous bound makes impossible
for route messages in practice.
Signed-off-by: Sorah Fukumori <her@sorah.jp>
