I believe that the wording of the spec has always allowed unicast signals,
but most bindings assume that signals are broadcasts, so it seems worth
saying specifically that this feature exists and can be useful.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=39450
Reviewed-by: Thiago Macieira <thiago@kde.org>
The spec previously claimed that only messages matching the client's
match rules would be received. This is not actually true: messages
listing a client as their DESTINATION are always delivered (security
policy permitting).
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=39450
Reviewed-by: Thiago Macieira <thiago@kde.org>
The Windows implementation is untested, but does at least (cross-)compile,
and matches what GLib does.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=38005
Reviewed-by: Lennart Poettering <lennart@poettering.net>
INCLUDES is a deprecated way to get the same effect as AM_CPPFLAGS.
It's harmless to add extra -I directories to all the tests, even those
that use neither GLib nor dbus-glib, so we can simplify by setting these
AM_CPPFLAGS for the whole directory.
If we change the default assumption to be that new tests will be
dynamically-linked to libdbus, those tests can be useful for
installcheck or even for installation. Accordingly, explicitly use
new variable $(static_cppflags) for all tests that need static linking.
Everything in this directory is statically linked to libdbus-internal,
so we can make -DDBUS_STATIC_BUILD global. Also, merge INCLUDES into
AM_CPPFLAGS (it's an older name for the same functionality).
This is the library used by tests that link libdbus-internal and DBusLoop.
By linking libdbus-internal into it, we can avoid having to repeat that
dependency all over the place - libtool and cmake both know how to follow
recursive dependencies.
In cmake, also use libdbus-testutils for more tests, in preference to
repeating its source files.
These tests get everything they need from the public or internal API of
libdbus-internal.la, and libtool knows how to pull in libraries'
dependencies, so we don't need explicit linking.
spawn-test and break-loader don't actually need test-utils.[ch]
either.
This does still need to be in configure.ac, because it's common to
dbus/Makefile.am (linking the static/shared library) and dbus-1*.pc.in
(telling static library users which additional libraries they must link).
* dbus-send, dbus-uuidgen only need to link libdbus; libtool knows what
extra libraries libdbus depends on
* dbus-monitor uses a Winsock header (on Windows) so it needs
NETWORK_libs,but still doesn't need threads
* dbus-launch needs X (on Unix) but doesn't directly need threads or
networking
In order to allow D-Bus usage during early boot (where /usr is not
accessible) also search for bus activation files in
/lib/dbus-1/system-services/. This is only a first step in the right
direction, before we really can boot without /usr we'd need to move all
current activation files (or possibly replace
/usr/dbus-1/system-services to a symlink to
/lib/dbus-1/system-services).
The number of messages is arbitrary; the more messages, the more likely
the crash is. 2000 messages seem to cause it reliably on this laptop,
but I've set it to 10000 to be safe.
Reviewed-by: Colin Walters <walters@verbum.org>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=34393
With fd.o#34393 fixed, retaking the lock to cache unused links
significantly adds to locking overhead (-18% throughput in a synthetic
benchmark on an ARM device). The cache is also unlimited in size, and
probably contributes to memory growth and fragmentation by not being
under the system malloc's control.
Fixing fd.o #34393, but also dropping this cache entirely, turns out to
lead to a 5% increase in throughput on the same synthetic benchmark.
Reviewed-by: Colin Walters <walters@verbum.org>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=34393
Finalizing a message can trigger callbacks; that's bad, if we have a
connection locked.
In particular, if a message is received by the "left side", passed to
the "right side" and sent (as in test/relay.c (see the diagram there)
or in dbus-daemon), then finalizing that message could result in the
live messages counter for the left side, and the outgoing messages counter
for the right side, both being decremented while under either side's
lock.
After a message is dispatched on the left side, finalizing it now drops
the lock temporarily, to avoid this problem.
After a message is sent on the right side, finalizing it is now deferred
until the right side unlocks, by moving it to a new queue of
"expired messages" which is automatically cleared every time we release
the lock.
The "live messages" counter for the "left" connection will now explicitly
take the left connection's lock before decrementing, to avoid
manipulating watches without a lock.
Reviewed-by: Colin Walters <walters@verbum.org>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=34393
It's about to become more complex, to handle delayed deallocation of
messages in order to avoid triggering callbacks while locked.
Reviewed-by: Colin Walters <walters@verbum.org>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=34393
In all the places where counters are added, we're under a lock. The caller
knows what effect adding the counter might have, and can replicate it
in a lock-safe way if necessary.
Reviewed-by: Colin Walters <walters@verbum.org>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=34393
