| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The rules are:
* symbols in libdbus-1 with neither decoration are private to libdbus-1
* symbols in libdbus-1 with DBUS_EXPORT are public API
* symbols in libdbus-1 with DBUS_PRIVATE_EXPORT are private to the
dbus source package, but may be used by other programs in the dbus
source tree, including tests
* symbols in libdbus-internal must not have DBUS_EXPORT or
DBUS_PRIVATE_EXPORT, and should be used by as few things as possible
Thanks to Ralf Habacker for his contributions to this rather
large commit.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=83115
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
|
| |
|
|
|
|
|
|
|
|
| |
systems"
This reverts commit 83aaa9f359e90d3b8cae5d17f6d9ba4600cff68b.
This wasn't right: because it looked for a symbol from pthread.h,
modules could end up disagreeing about whether threading was enabled or
not.
|
| |
|
|
|
|
|
| |
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=54972
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Alban Crequy <alban.crequy@collabora.co.uk>
Reviewed-by: Anas Nashif <anas.nashif@intel.com>
|
| |
|
|
|
|
|
|
| |
Neither was used, and the Windows version could lead to live-locks.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=43744
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=44609
Reviewed-by: Thiago Macieira <thiago@kde.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This lets us simplify considerably, by assuming that we always have both
recursive and suitable-for-condition-variable mutexes.
The Windows implementation has been compiled (on 32-bit mingw-w64)
but not tested. Justification for the approach used on Windows,
and in particular, using the existing "non-recursive" locks as if
they were recursive:
* We've been using them in conjunction with condition variables all
along, so they'd better be suitable
* On fd.o #36204, Ralf points out that mutexes created via CreateMutex
are, in fact, recursive
* Havoc's admonitions about requiring "Java-style" recursive locking
(waiting for a condition variable while holding a recursive lock
requires releasing that lock n times) turn out not to apply to
either of our uses of DBusCondVar in DBusConnection, because the
lock is only held for a short time, without calling into user code;
indeed, our Unix implementation isn't recursive anyway, so if
the Windows implementation reaches the deadlocking situation
somehow (waiting for condition variable while locked more than once),
the Unix implementation would already have deadlocked on the same
code path (trying to lock more than once)
One possible alternative to a CreateMutex mutex for use with condition
variables would be a CRITICAL_SECTION. I'm not going to implement this,
but Windows developers are welcome to do so.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=36204
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=43744
Reviewed-by: Thiago Macieira <thiago@kde.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
dbus-threads.h warns that recursive pthreads mutexes are not compatible
with our expectations for condition variables. However, the only two
condition variables we actually use only have their corresponding
mutexes locked briefly (and we don't call out to user code from there),
so the mutexes don't need to be recursive anyway. That's just as well,
because it turns out our implementation of recursive mutexes on
pthreads is broken!
The goal here is to be able to distinguish between "cmutexes" (mutexes
compatible with a condition variable) and "rmutexes" (mutexes which
are recursive if possible, to avoid deadlocking if we hold them while
calling user code).
This is complicated by the fact that callers are not guaranteed to have
provided us with both versions of mutexes, so we might have to implement
one by using the other (in particular, DBusRMutex *aims to be*
recursive, it is not *guaranteed to be* recursive).
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=43744
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Thiago Macieira <thiago@kde.org>
|
| |
|
|
|
|
|
|
| |
They're only called within their module.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=43744
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Thiago Macieira <thiago@kde.org>
|
| |
|
|
|
|
| |
No comment.
Signed-off-by: Colin Walters <walters@verbum.org>
|
| |
|
|
| |
* Add indent-tabs-mode: nil to all file headers.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
* dbus/dbus-threads.[hc]: Documentation improvements. Clarify how
condition variables relate to recursive mutexes.
* dbus/dbus-sysdeps-pthread.c, dbus/dbus-sysdeps-win-thread.c,
dbus/dbus-threads.c: Split the platforms-specific thread
implementations into their own files.
* dbus/dbus-sysdeps-pthread.c
(_dbus_pthread_condvar_wait_timeout): invert the return value, it
was backward. Not that anything uses it.
|
| |
|
|
|
|
|
| |
dbus_threads_init and be used by the dbus mutex functions to
avoid deadlocks.
* doc/TODO: Remove recursive mutex dbus_connection_dispatch TODO item
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
static DBusList *uninitialized_condvar_list to support new late
initialization threading model. In this model threads can be initialized
even after the D-Bus API has been used but still needs to be initialized
before the second thread has been started. Mutexes and condvar addresses
are stored in the two static lists and are replaced with actuall locks
when threads are initalized.
(_dbus_mutex_new_at_location): New method for creating a mutex and placing
the location into the static list
(_dbus_mutex_free_at_location): New method for removing a mutex location
from the static list and freeing the mutex
(_dbus_condvar_new_at_location): New method for creating a conditional
variable and placing the location into the static list
(_dbus_condvar_free_at_location): New method for removing a conditional
variable location from the static list and freeing the conditional variable
(init_uninitialized_locks): Atomic method which goes through the static
lists of mutex and condvar location and updates them with actuall locks
(init_global_locks): changed to init_locks
* dbus/dbus-connection.c:
(_dbus_connection_test_get_locks): New method for tests to check connections
(_dbus_connection_new_for_transport): Use the new at_location mutex and
condvar API
(dbus_connection_allocate_data_slot): Pass in the global lock address
to _dbus_data_slot_allocator_alloc
* dbus/dbus-dataslot.c:
(_dbus_data_slot_allocator_alloc): Use the address of the mutex
instead of the mutex itself
* dbus/dbus-message.c:
(dbus_message_allocate_data_slot): Pass in the global lock address
to _dbus_data_slot_allocator_alloc
* dbus/dbus-pending-call.c:
(dbus_pending_call_allocate_data_slot): Pass in the global lock address
to _dbus_data_slot_allocator_alloc
* dbus/dbus-server.c:
(_dbus_server_init_base): Use the new at_location mutex API
(dbus_server_allocate_data_slot): Pass in the global lock address
to _dbus_data_slot_allocator_alloc
* test/name-test/test-threads-init.c: New test case for late thread
initialization
|
| | |
|
| |
|
