This should mean we don't get invalid fds in the main loop.
The BSD (kqueue) and Windows code paths are untested, but follow the same
patterns as the tested Linux/generic Unix versions.
DBusTransportSocket was already OK (it called free_watches() before
_dbus_close_socket, and that did the remove, invalidate, unref dance).
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=33336
Reviewed-by: Will Thompson <will.thompson@collabora.co.uk>
Reviewed-by: Thiago Macieira <thiago@kde.org>
The documentation claimed that INT_MAX (whatever that means) meant the
default, but the value that has actually always been checked for is
0x7fffffff (aka INT32_MAX on the competent platforms we sadly don't
restrict our portability to), so we should use that. (In practice D-Bus
probably never worked on platforms where int wasn't 32 bits, though.)
Reviewed-by: Will Thompson <will.thompson@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=34570
That probably won't work, because it'll find the system-wide library
which might be older.
Reviewed-by: Will Thompson <will.thompson@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=34570
This just pushes 2000 messages (or 100000 in performance-testing mode)
through the dbus-daemon, to an echo service and back.
Reviewed-by: Will Thompson <will.thompson@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=34570
This will allow modular tests to spawn a dbus-daemon with a specified
config file; nothing uses this just yet.
Reviewed-by: Will Thompson <will.thompson@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=34570
For the moment, the CMake build system only knows about the existing
"embedded tests"; make it define both symbols, though.
We use GLib because it has GTester (and life's too short to write yet another
JUnit clone), and dbus-glib for the main-loop integration only (see
fd.o #31515 for thoughts on incorporating just those two functions in a
separate library in the dbus tarball).
I'm not using DBusLoop for the main loop because I specifically don't
want to use non-public API or ABI of libdbus in the modular tests. If we make
sure they work against a shared libdbus, we can use them to test the
installed system, with "make installcheck".
Reviewed-by: Will Thompson <will.thompson@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=34570
We no longer use GLib internally, and assertions are how it'll report test
failures when we add GTest-based tests.
Reviewed-by: Will Thompson <will.thompson@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=34570
It's entirely possible for a message to indicate how many bytes we need,
without actually being complete.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=38120
Reviewed-by: Will Thompson <will.thompson@collabora.co.uk>
Trying to mix atomic operations with locked non-atomic operations is
broken: the atomic ops aren't necessarily atomic with respect to the
locked non-atomic ops, and the non-atomic ops aren't protected by the
lock because the atomic ops can change the refcount behind their back.
In theory we could use the connection lock if atomic ops aren't supported
(making a per-connection lock cheaper than the global lock used to
implement atomic ops) *and* our mutexes are recursive (making it safe
against deadlocks)... but life's too short.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=38005
Tested-by: Will Manley <freedesktop williammanley net>
Reviewed-by: Will Thompson <will.thompson@collabora.co.uk>
Using $(LN_S) is inappropriate because it could in theory mean either
ln -s, ln or cp -p depending on autoconf checks.
Not using -f breaks reinstallation directly from source (DESTDIR unset),
because the symlinks will already exist.
Because systemd isn't currently portable to non-Linux, let alone
non-SUS-compliant systems, it seems safe to assume that ln -fs behaves
as specified by SUS if systemd was found.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=37870
Reviewed-by: Colin Walters <walters@verbum.org>
Packagers should only enable this flag if they have confirmed that it
actually works on their toolchain (it's the sort of rarely used feature
that frequently regresses on obscure architectures/OSs without anyone
noticing), and also confirmed that it is actually a significant size win
for their configuration.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=33466
Reviewed-by: Colin Walters <walters@verbum.org>
