-
Simon McVittie authored
This changes the meaning of "properties_lock" from "lock for D-Bus properties" to "lock for GObject properties". The most common problem, and the only one I've reproduced in a regression test, is name_owner, which can be updated by the thread that owns the GDBusProxy's main context (i.e. the thread-default main context of the thread that constructed it) at the same time that a blocking call is made. When a GDBusProxy is constructed in a thread-pool thread for short-term use, the main context will typically be the global default main context (which is actively running in the main thread!), making this extremely problematic. The interface info is perhaps a theoretical concern - one thread could conceivably set it at the same time that another thread uses it, but only in relatively pathological situations. The current API for this does have the problem that it returns a borrowed ref, but interface info is hopefully permanent anyway. The default timeout is probably only a theoretical concern - it's just an int, so writes are indivisible, and there's no worry about whether something has been freed - but to be safe, let's hold the lock for that too. Bug: https://bugzilla.gnome.org/show_bug.cgi?id=656039 Bug-NB: NB#259760 Signed-off-by: David Zeuthen <davidz@redhat.com>
85214d1e